Dear Alexei, I think you miss the point. A typical situation were the generation of C code is useful, is the following: You use GiNaC to compute symbolically a rather large expression which depends on a handful symbols. You then want to evaluate this expression numerically a large number of times for different values of the variables/symbols ( a typical example is Monte Carlo integration). There are two large quantities in the game: The size of the expression and the number of evaluations. I believe an efficient way to do this is to write the expression as C code into a file, compile and reload the compiled function into memory. There is certainly an overhead involved for the time needed to generate the C code and the compilation, but this occurs only once and is usually outweighted by the speed improvement of a single evaluation. To give an example I took an expression, which I want to evaluate 10^6 times. A single evaluation with evalf() takes 0.55 s. If I use the plain print_csrc routine build into GiNaC, the code is generated in less than a second, compilation takes 74s, but the time for a single evaluation improves to 3.8 10^-3 s. If I take the routine for the generation of optimized code, code generation takes 49s (yes, code optimization has a price, but you pay only once), compilation takes 7 s, and the time for a single evaluation is now 3.2 10^-4 s. So the total cost for one million evaluations is evalf() : 550000 s standard csrc: 3875 s optimized: 376 s Therefore I don't understand why you propose evalf(), the difference in cost are orders of magnitude. A few more comments: I agree that GiNaC is not a compiler, but a nice feature is that it is based on C++ and should therefore allow the combination of symbolic and numerical code. Generating optimized C code is a feature I miss in GiNaC. Finally, one should make the attempt to generate "the" optimal code, anything which performs better than the standard csrc output is already an improvment. Best wishes, Stefan