Constructing expressions with strings for a generated function is definitely much more complicated and harder to read. And it'll almost certainly take more resources and time during compilation.
You'll probably also be very interested in Base.Cartesian. See the developer documentation here: http://docs.julialang.org/en/latest/devdocs/cartesian/ For example, I think this: inner_prod_numerator = "f[" for i = 1:N if i == N inner_prod_numerator = string("poly[",i,"][s",i,",i",i,"]*", inner_prod_numerator,"s",i) else inner_prod_numerator = string("poly[",i,"][s",i,",i",i,"]*", inner_prod_numerator,"s",i,",") end end inner_prod_numerator = string(inner_prod_numerator,"]") numerator_term = parse(inner_prod_numerator) can be simplified to: :(@ncall(3, *, d->poly[d][s_d,i_d])) Note that you have to name your variables with underscores to make use of Base.Cartesian, so s3 becomes s_3, but I think you'll find it much simpler to lean on the existing functionality. Check out `macroexpand` to see what these macros do. julia> macroexpand(:(@ncall(3, *, d->poly[d][s_d,i_d]))) :((poly[1])[s_1,i_1] * (poly[2])[s_2,i_2] * (poly[3])[s_3,i_3]) Matt On Sunday, June 12, 2016 at 7:07:17 PM UTC-5, Kristoffer Carlsson wrote: > > Yes the splatting is the problem. But since you are using a generated > function you can just generate code to avoid splatting. > > Evaling a string should on 0.4 not affect the performance of the generated > function but on 0.5 I think you can't even call eval in generated functions > (for technical reasons). >
