Why is Func<> created from Expression<Func<>> slower than Func<> declared directly?

Question

Why is a Func<> created from an Expression<Func<>> via .Compile() considerably slower than just using a Func<> declared directly ?

I just changed from using a Func<IInterface, object> declared directly to one created from an Expression<Func<IInterface, object>> in an app i am working on and i noticed that the performance went down.

I have just done a little test, and the Func<> created from an Expression takes "almost" double the time of an Func<> declared directly.

On my machine the Direct Func<> takes about 7.5 seconds and the Expression<Func<>> takes about 12.6 seconds.

Here is the test code I used (running Net 4.0)

// Direct Func<int, Foo> test1 = x => new Foo(x * 2);  int counter1 = 0;  Stopwatch s1 = new Stopwatch(); s1.Start(); for (int i = 0; i < 300000000; i++) {  counter1 += test1(i).Value; } s1.Stop(); var result1 = s1.Elapsed;    // Expression . Compile() Expression<Func<int, Foo>> expression = x => new Foo(x * 2); Func<int, Foo> test2 = expression.Compile();  int counter2 = 0;  Stopwatch s2 = new Stopwatch(); s2.Start(); for (int i = 0; i < 300000000; i++) {  counter2 += test2(i).Value; } s2.Stop(); var result2 = s2.Elapsed;    public class Foo {  public Foo(int i)  {   Value = i;  }  public int Value { get; set; } } 

How can i get the performance back ?

Is there anything i can do to get the Func<> created from the Expression<Func<>> to perform like one declared directly ?

Answer 1

As others have mentioned, the overhead of calling a dynamic delegate is causing your slowdown. On my computer that overhead is about 12ns with my CPU at 3GHz. The way to get around that is to load the method from a compiled assembly, like this:

var ab = AppDomain.CurrentDomain.DefineDynamicAssembly(              new AssemblyName("assembly"), AssemblyBuilderAccess.Run); var mod = ab.DefineDynamicModule("module"); var tb = mod.DefineType("type", TypeAttributes.Public); var mb = tb.DefineMethod(              "test3", MethodAttributes.Public | MethodAttributes.Static); expression.CompileToMethod(mb); var t = tb.CreateType(); var test3 = (Func<int, Foo>)Delegate.CreateDelegate(                 typeof(Func<int, Foo>), t.GetMethod("test3"));  int counter3 = 0; Stopwatch s3 = new Stopwatch(); s3.Start(); for (int i = 0; i < 300000000; i++) {     counter3 += test3(i).Value; } s3.Stop(); var result3 = s3.Elapsed; 

When I add the above code, result3 is always just a fraction of a second higher than result1, for about a 1ns overhead.

So why even bother with a compiled lambda (test2) when you can have a faster delegate (test3)? Because creating the dynamic assembly is much more overhead in general, and only saves you 10-20ns on each invocation.

Answer 2

(This is not a proper answer, but is material intended to help discover the answer.)

Statistics gathered from Mono 2.6.7 - Debian Lenny - Linux 2.6.26 i686 - 2.80GHz single core:

      Func: 00:00:23.6062578 Expression: 00:00:23.9766248 

So on Mono at least both mechanisms appear to generate equivalent IL.

This is the IL generated by Mono's gmcs for the anonymous method:

// method line 6 .method private static  hidebysig        default class Foo '<Main>m__0' (int32 x)  cil managed {     .custom instance void class [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::'.ctor'() =  (01 00 00 00 ) // ....      // Method begins at RVA 0x2204     // Code size 9 (0x9)     .maxstack 8     IL_0000:  ldarg.0     IL_0001:  ldc.i4.2     IL_0002:  mul     IL_0003:  newobj instance void class Foo::'.ctor'(int32)     IL_0008:  ret } // end of method Default::<Main>m__0 

I will work on extracting the IL generated by the expression compiler.