Question

Suppose I have written such a class (number of functions doesn’t really matter, but in real, there will be somewhere about 3 or 4).

    private class ReallyWeird
    {
        int y;

        Func<double, double> f1;
        Func<double, double> f2;
        Func<double, double> f3;

        public ReallyWeird()
        {
            this.y = 10;

            this.f1 = (x => 25 * x + y);
            this.f2 = (x => f1(x) + y * f1(x));
            this.f3 = (x => Math.Log(f2(x) + f1(x)));
        }

        public double CalculusMaster(double x)
        {
            return f3(x) + f2(x);
        }
    }

I wonder if the C# compiler can optimize such a code so that it won’t go through numerous stack calls.

Is it able to inline delegates at compile-time at all? If yes, on which conditions and to which limits? If no, is there an answer why?

Another question, maybe even more important: will it be significantly slower than if I had declared f1, f2 and f3 as methods?

I ask this because I want to keep my code as DRY as possible, so I want to implement a static class which extends the basic random number generator (RNG) functionality: its methods accept one delegate (e.g. from method NextInt() of the RNG) and returning another Func delegate (e.g. for generating ulongs), built on top of the former. and as long as there are many different RNG’s which can generate ints, I prefer not to think about implementing all the same extended functionality ten times in different places.

So, this operation may be performed several times (i.e. initial method of the class may be ‘wrapped’ by a delegate twice or even three times). I wonder what will be the performance overhead like.

Thank you!

Answer 1

If you use Expression Trees instead of complete Func<> the compiler will be able to optimize the expressions.

Edit To clarify, note that I’m not saying the runtime would optimize the expression tree itself (it shouldn’t) but rather that since the resulting Expression<> tree is .Compile()d in one step, the JIT engine will simply see the repeated subexpressions and be able to optimize, consolidate, substitue, shortcut and what else it does normally.

(I’m not absolutely sure that it does on all platforms, but at least it should be able to fully leverage the JIT engine)

---

Comment response

• First, expression trees has in potential shall equal execution speed as Func<> (however a Func<> will not have the same runtime cost – JITting probably takes place while jitting the enclosing scope; in case of ngen, it will even be AOT, as opposed to an expresseion tree)

• Second: I agree that Expression Trees can be hard to use. See here for a famous simple example of how to compose expressions. However, more complicated examples are pretty hard to come by. If I’ve got the time I’ll see whether I can come up with a PoC and see what MS.Net and MONO actually generate in MSIL for these cases.

• Third: don’t forget Henk Holterman is probably right in saying this is premature optimization (although composing Expression<> instead of Func<> ahead of time just adds the flexibility)

• Lastly, when you really think about driving this very far, you might consider using Compiler As A Service (which Mono already has, I believe it is still upcoming for Microsoft?).