I am trying to use `Symbolics.build_function`

to generate `JuMP.AffExpr`

expressions from symbolic expressions.

I see an error message

```
Internal error: stack overflow in type inference of (::RuntimeGeneratedFunctions.RuntimeGeneratedFunction{(:ˍ₋arg1, :ˍ₋arg2, :ˍ₋arg3, :λ_slope, :λ_sector, :P, :ζ²), Symbolics.var"#_RGF_ModTag", Symbolics.var"#_RGF_ModTag", (0xc10ed7fe, 0x47ee3867, 0xeabcab9f, 0x039a29c4, 0x30209ded), Expr})(Array{JuMP.GenericAffExpr{Float64, JuMP.GenericVariableRef{Float64}}, 2}, Array{JuMP.GenericAffExpr{Float64, JuMP.GenericVariableRef{Float64}}, 2}, Array{JuMP.GenericAffExpr{Float64, JuMP.GenericVariableRef{Float64}}, 2}, JuMP.GenericVariableRef{Float64}, JuMP.GenericVariableRef{Float64}, Array{JuMP.GenericVariableRef{Float64}, 2}, Float64).
This might be caused by recursion over very long tuples or argument lists.
```

I would like to understand what measure of complicatedness is problematic for `build_function`

and how well I should expect it to scale. (There was a thread [1] earlier with a comment that mentioned “tens of thousands of variables” as a notion of a large function, and I have much fewer than that.)

As can be seen in the error message, the function has only 7 arguments and those are mostly matrices of JuMP expressions. The matrices used as arguments are not very large (diagonal matrices of size around 30x30 or dense of size 4x4). `Symbolics.substitute`

replaces the variables in around 4 seconds, and I was hoping for `build_function`

to offer a faster alternative as I want to perform the same optimization many times while varying parameter values and on new JuMP models.

(I suspect the right solution to my problem may involve reusing JuMP models instead, and replacing parameters in those, but this questions is one step along the way of testing different options, and I have not yet looked for information on reusing JuMP models.)

[1] Compiling large Symbolics.jl expressions using build_function - #3 by ChrisRackauckas