157

I have a question about the performance of dynamic in C#. I've read dynamic makes the compiler run again, but what does it do?

Does it have to recompile the whole method with the dynamic variable used as a parameter or just those lines with dynamic behavior/context?

I've noticed that using dynamic variables can slow down a simple for loop by 2 orders of magnitude.

Code I have played with:

internal class Sum2
{
    public int intSum;
}

internal class Sum
{
    public dynamic DynSum;
    public int intSum;
}

class Program
{
    private const int ITERATIONS = 1000000;

    static void Main(string[] args)
    {
        var stopwatch = new Stopwatch();
        dynamic param = new Object();
        DynamicSum(stopwatch);
        SumInt(stopwatch);
        SumInt(stopwatch, param);
        Sum(stopwatch);

        DynamicSum(stopwatch);
        SumInt(stopwatch);
        SumInt(stopwatch, param);
        Sum(stopwatch);

        Console.ReadKey();
    }

    private static void Sum(Stopwatch stopwatch)
    {
        var sum = 0;
        stopwatch.Reset();
        stopwatch.Start();
        for (int i = 0; i < ITERATIONS; i++)
        {
            sum += i;
        }
        stopwatch.Stop();

        Console.WriteLine(string.Format("Elapsed {0}", stopwatch.ElapsedMilliseconds));
    }

    private static void SumInt(Stopwatch stopwatch)
    {
        var sum = new Sum();
        stopwatch.Reset();
        stopwatch.Start();
        for (int i = 0; i < ITERATIONS; i++)
        {
            sum.intSum += i;
        }
        stopwatch.Stop();

        Console.WriteLine(string.Format("Class Sum int Elapsed {0}", stopwatch.ElapsedMilliseconds));
    }

    private static void SumInt(Stopwatch stopwatch, dynamic param)
    {
        var sum = new Sum2();
        stopwatch.Reset();
        stopwatch.Start();
        for (int i = 0; i < ITERATIONS; i++)
        {
            sum.intSum += i;
        }
        stopwatch.Stop();

        Console.WriteLine(string.Format("Class Sum int Elapsed {0} {1}", stopwatch.ElapsedMilliseconds, param.GetType()));
    }

    private static void DynamicSum(Stopwatch stopwatch)
    {
        var sum = new Sum();
        stopwatch.Reset();
        stopwatch.Start();
        for (int i = 0; i < ITERATIONS; i++)
        {
            sum.DynSum += i;
        }
        stopwatch.Stop();

        Console.WriteLine(String.Format("Dynamic Sum Elapsed {0}", stopwatch.ElapsedMilliseconds));
    }
Quality Catalyst
  • 6,531
  • 8
  • 38
  • 62
Lukasz Madon
  • 14,664
  • 14
  • 64
  • 108
  • No, it doesn't run the compiler, that would make it punishing slow on the first pass. Somewhat similar to Reflection but with lots of smarts to keep track of what was done before to minimize the overhead. Google "dynamic language runtime" for more insight. And no, it will never approach the speed of a 'native' loop. – Hans Passant Sep 19 '11 at 23:46
  • also see http://stackoverflow.com/questions/3784317/c-sharp-dynamic-keyword-run-time-penalty – nawfal May 06 '13 at 11:14

2 Answers2

263

I've read dynamic makes the compiler run again, but what it does. Does it have to recompile whole method with the dynamic used as a parameter or rather those lines with dynamic behavior/context(?)

Here's the deal.

For every expression in your program that is of dynamic type, the compiler emits code that generates a single "dynamic call site object" that represents the operation. So, for example, if you have:

class C
{
    void M()
    {
        dynamic d1 = whatever;
        dynamic d2 = d1.Foo();

then the compiler will generate code that is morally like this. (The actual code is quite a bit more complex; this is simplified for presentation purposes.)

class C
{
    static DynamicCallSite FooCallSite;
    void M()
    {
        object d1 = whatever;
        object d2;
        if (FooCallSite == null) FooCallSite = new DynamicCallSite();
        d2 = FooCallSite.DoInvocation("Foo", d1);

See how this works so far? We generate the call site once, no matter how many times you call M. The call site lives forever after you generate it once. The call site is an object that represents "there's going to be a dynamic call to Foo here".

OK, so now that you've got the call site, how does the invocation work?

The call site is part of the Dynamic Language Runtime. The DLR says "hmm, someone is attempting to do a dynamic invocation of a method foo on this here object. Do I know anything about that? No. Then I'd better find out."

The DLR then interrogates the object in d1 to see if it is anything special. Maybe it is a legacy COM object, or an Iron Python object, or an Iron Ruby object, or an IE DOM object. If it is not any of those then it must be an ordinary C# object.

This is the point where the compiler starts up again. There's no need for a lexer or parser, so the DLR starts up a special version of the C# compiler that just has the metadata analyzer, the semantic analyzer for expressions, and an emitter that emits Expression Trees instead of IL.

The metadata analyzer uses Reflection to determine the type of the object in d1, and then passes that to the semantic analyzer to ask what happens when such an object is invoked on method Foo. The overload resolution analyzer figures that out, and then builds an Expression Tree -- just as if you'd called Foo in an expression tree lambda -- that represents that call.

The C# compiler then passes that expression tree back to the DLR along with a cache policy. The policy is usually "the second time you see an object of this type, you can re-use this expression tree rather than calling me back again". The DLR then calls Compile on the expression tree, which invokes the expression-tree-to-IL compiler and spits out a block of dynamically-generated IL in a delegate.

The DLR then caches this delegate in a cache associated with the call site object.

Then it invokes the delegate, and the Foo call happens.

The second time you call M, we already have a call site. The DLR interrogates the object again, and if the object is the same type as it was last time, it fetches the delegate out of the cache and invokes it. If the object is of a different type then the cache misses, and the whole process starts over again; we do semantic analysis of the call and store the result in the cache.

This happens for every expression that involves dynamic. So for example if you have:

int x = d1.Foo() + d2;

then there are three dynamic calls sites. One for the dynamic call to Foo, one for the dynamic addition, and one for the dynamic conversion from dynamic to int. Each one has its own runtime analysis and its own cache of analysis results.

Make sense?

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • Just out of curiosity, the special compiler version without parser/lexer is invoked by passing a special flag to the standard csc.exe? – Roman Royter Sep 20 '11 at 15:00
  • @Eric, can I trouble you to point me to a previous blog post of yours where you talk about implicit conversions of short, int, etc? As I recall you mentioned in there how/why using dynamic with Convert.ToXXX causes the compiler to fire up. I'm sure I'm butchering the details, but hopefully you know what I'm talking about. – Adam Rackis Sep 20 '11 at 15:49
  • 6
    @Roman: No. csc.exe is written in C++, and we needed something we could easily call from C#. Also, the mainline compiler has its own type objects, but we needed to be able to use Reflection type objects. We extracted the relevant portions of the C++ code from the csc.exe compiler and translated them line-by-line into C#, and then built a library out of that for the DLR to call. – Eric Lippert Sep 20 '11 at 16:54
  • @Adam: I think you are thinking of this one: http://blogs.msdn.com/b/ericlippert/archive/2009/03/19/representation-and-identity.aspx – Eric Lippert Sep 20 '11 at 16:55
  • 12
    @Eric, "We extracted the relevant portions of the C++ code from the csc.exe compiler and translated them line-by-line into C#" was it about then people thought Roslyn might be worth pursuing :) – ShuggyCoUk Sep 20 '11 at 17:58
  • 7
    @ShuggyCoUk: The idea of having a compiler-as-a-service had been kicking around for some time, but actually needing a runtime service do to code analysis was a big impetus towards that project, yes. – Eric Lippert Sep 20 '11 at 18:23
  • Or an `IDynamicMetaObjectProvider`? – configurator Sep 27 '11 at 15:51
  • What does interrogate means? Does it call overrides from DynamicObject? Or does it use reflection? What if I have two objects of type class Entity : DynamicObject, but their method TryGetMember will have different set of members - will the cache miss? – Sergiy Belozorov Aug 16 '13 at 15:58
  • Re: the cache policy passed back by the special compiler: "the second time you see an object of this type, you can re-use this expression tree rather than calling me back again". Does that still work if you're trying to invoke a different method? – Asad Saeeduddin Oct 14 '15 at 21:29
  • @AsadSaeeduddin: If the receiver is of the same type then how can the method Foo resolve to a different method? – Eric Lippert Oct 15 '15 at 05:25
  • How many dynamic call sites would you get for a `DynamicObject` derived class with some 100 properties? And will those call sites be cached *once* per concrete type? E.g. Will `class MyObject : DynamicObject` have 100 call sites for every `T`, or worse? – l33t Dec 12 '20 at 00:28
  • @l33t: I think you might have some misunderstanding here. A "dynamic call site" corresponds to a location in your source code where a dynamic call is made; that's why they're called "call sites". As I said above, you get one call site per call *in the source code*, no matter how many times that call is executed after the first time. – Eric Lippert Dec 14 '20 at 15:45
  • So if I understand correctly && if a dynamic type alternates on each call, the caching will be useless. For example, if `d1` type comes from the following list on each consecutive call: `double, int, double, int, ...`. What was the reason for not having cache as a dictionary (types for keys, delegates for values)? – Nikola Malešević Feb 19 '21 at 06:35
  • 1
    @NikolaMalešević: The cache is a dictionary. Sorry if I implied it was not; that was not my intention. – Eric Lippert Feb 19 '21 at 23:22
  • 1
    @NikolaMalešević: More generally, there are multiple possible caches for the different policies. There is a "cache this call site for arguments of these types" policy, there's a "cache this call site but just for these specific arguments" policy, there's a "don't cache this one" policy, and maybe more that I've forgotten in the fifteen years between now and when I last looked at that code. – Eric Lippert Feb 19 '21 at 23:24
  • @EricLippert, what happens if we cast to dynamic within a loop? For example, would `int x = 0; for (int i = 0; i < 1000; i++) { (dynamic)x++ }` have worse performance than `dynamic x = 0; for (int i = 0; i < 1000; i++) { x++ }`? – Thomas Darling Dec 14 '21 at 16:47
  • And what about a scenario, where a new variable is declared within a loop, and then cast to dynamic: `int x = 0; for (int i = 0; i < 1000; i++) { int y = 1; x += (dynamic)y }`? The examples are obviously unrealistic, but hopefully they illustrate the point - I guess the core of my question is whether a call site is _literally_ a location in my source code, or if it is something that would be repeated in a loop, as I think this old bug may imply https://github.com/dotnet/runtime/issues/18655 – Thomas Darling Dec 14 '21 at 16:57
124

Update: Added precompiled and lazy-compiled benchmarks

Update 2: Turns out, I'm wrong. See Eric Lippert's post for a complete and correct answer. I'm leaving this here for the sake of the benchmark numbers

*Update 3: Added IL-Emitted and Lazy IL-Emitted benchmarks, based on Mark Gravell's answer to this question.

To my knowledge, use of the dynamic keyword does not cause any extra compilation at runtime in and of itself (though I imagine it could do so under specific circumstances, depending on what type of objects are backing your dynamic variables).

Regarding performance, dynamic does inherently introduce some overhead, but not nearly as much as you might think. For example, I just ran a benchmark that looks like this:

void Main()
{
    Foo foo = new Foo();
    var args = new object[0];
    var method = typeof(Foo).GetMethod("DoSomething");
    dynamic dfoo = foo;
    var precompiled = 
        Expression.Lambda<Action>(
            Expression.Call(Expression.Constant(foo), method))
        .Compile();
    var lazyCompiled = new Lazy<Action>(() =>
        Expression.Lambda<Action>(
            Expression.Call(Expression.Constant(foo), method))
        .Compile(), false);
    var wrapped = Wrap(method);
    var lazyWrapped = new Lazy<Func<object, object[], object>>(() => Wrap(method), false);
    var actions = new[]
    {
        new TimedAction("Direct", () => 
        {
            foo.DoSomething();
        }),
        new TimedAction("Dynamic", () => 
        {
            dfoo.DoSomething();
        }),
        new TimedAction("Reflection", () => 
        {
            method.Invoke(foo, args);
        }),
        new TimedAction("Precompiled", () => 
        {
            precompiled();
        }),
        new TimedAction("LazyCompiled", () => 
        {
            lazyCompiled.Value();
        }),
        new TimedAction("ILEmitted", () => 
        {
            wrapped(foo, null);
        }),
        new TimedAction("LazyILEmitted", () => 
        {
            lazyWrapped.Value(foo, null);
        }),
    };
    TimeActions(1000000, actions);
}

class Foo{
    public void DoSomething(){}
}

static Func<object, object[], object> Wrap(MethodInfo method)
{
    var dm = new DynamicMethod(method.Name, typeof(object), new Type[] {
        typeof(object), typeof(object[])
    }, method.DeclaringType, true);
    var il = dm.GetILGenerator();

    if (!method.IsStatic)
    {
        il.Emit(OpCodes.Ldarg_0);
        il.Emit(OpCodes.Unbox_Any, method.DeclaringType);
    }
    var parameters = method.GetParameters();
    for (int i = 0; i < parameters.Length; i++)
    {
        il.Emit(OpCodes.Ldarg_1);
        il.Emit(OpCodes.Ldc_I4, i);
        il.Emit(OpCodes.Ldelem_Ref);
        il.Emit(OpCodes.Unbox_Any, parameters[i].ParameterType);
    }
    il.EmitCall(method.IsStatic || method.DeclaringType.IsValueType ?
        OpCodes.Call : OpCodes.Callvirt, method, null);
    if (method.ReturnType == null || method.ReturnType == typeof(void))
    {
        il.Emit(OpCodes.Ldnull);
    }
    else if (method.ReturnType.IsValueType)
    {
        il.Emit(OpCodes.Box, method.ReturnType);
    }
    il.Emit(OpCodes.Ret);
    return (Func<object, object[], object>)dm.CreateDelegate(typeof(Func<object, object[], object>));
}

As you can see from the code, I try to invoke a simple no-op method seven different ways:

  1. Direct method call
  2. Using dynamic
  3. By reflection
  4. Using an Action that got precompiled at runtime (thus excluding compilation time from the results).
  5. Using an Action that gets compiled the first time it is needed, using a non-thread-safe Lazy variable (thus including compilation time)
  6. Using a dynamically-generated method that gets created before the test.
  7. Using a dynamically-generated method that gets lazily instantiated during the test.

Each gets called 1 million times in a simple loop. Here are the timing results:

Direct: 3.4248ms
Dynamic: 45.0728ms
Reflection: 888.4011ms
Precompiled: 21.9166ms
LazyCompiled: 30.2045ms
ILEmitted: 8.4918ms
LazyILEmitted: 14.3483ms

So while using the dynamic keyword takes an order of magnitude longer than calling the method directly, it still manages to complete the operation a million times in about 50 milliseconds, making it far faster than reflection. If the method we call were trying to do something intensive, like combining a few strings together or searching a collection for a value, those operations would likely far outweigh the difference between a direct call and a dynamic call.

Performance is just one of many good reasons not to use dynamic unnecessarily, but when you're dealing with truly dynamic data, it can provide advantages that far outweigh the disadvantages.

Update 4

Based on Johnbot's comment, I broke the Reflection area down into four separate tests:

    new TimedAction("Reflection, find method", () => 
    {
        typeof(Foo).GetMethod("DoSomething").Invoke(foo, args);
    }),
    new TimedAction("Reflection, predetermined method", () => 
    {
        method.Invoke(foo, args);
    }),
    new TimedAction("Reflection, create a delegate", () => 
    {
        ((Action)method.CreateDelegate(typeof(Action), foo)).Invoke();
    }),
    new TimedAction("Reflection, cached delegate", () => 
    {
        methodDelegate.Invoke();
    }),

... and here are the benchmark results:

enter image description here

So if you can predetermine a specific method that you'll need to call a lot, invoking a cached delegate referring to that method is about as fast as calling the method itself. However, if you need to determine which method to call just as you're about to invoke it, creating a delegate for it is very expensive.

Community
  • 1
  • 1
StriplingWarrior
  • 151,543
  • 27
  • 246
  • 315
  • 2
    Such a detailed response, thanks! I was wondering about the actual numbers as well. – Sergey Sirotkin Sep 20 '11 at 00:09
  • 4
    Well, dynamic code starts up the metadata importer, semantic analyzer and expression tree emitter of the compiler, and then runs an expression-tree-to-il compiler on the output of that, so I think that it is fair to say that it starts up the compiler at runtime. Just because it doesn't run the lexer and the parser hardly seems relevant. – Eric Lippert Sep 20 '11 at 06:13
  • 8
    Your performance numbers certainly show how the aggressive caching policy of the DLR pays off. If your example did goofy things, like for instance if you had a different receiving type every time you did the call, then you'd see that the dynamic version is very slow when it cannot take advantage of its cache of previously-compiled analysis results. But when it *can* take advantage of that, holy goodness is it ever fast. – Eric Lippert Sep 20 '11 at 06:35
  • @EricLippert: Thanks for the correction, and for the enlightening post. Now it makes sense to me that `dynamic` takes only slightly longer than a Lazily-compiled method in these benchmarks. It's basically the same thing with just a little bit more runtime overhead. – StriplingWarrior Sep 20 '11 at 15:41
  • 1
    Something goofy as per Eric's suggestion. Test by swapping which line is commented. 8964ms vs 814ms, with `dynamic` of course losing: `public class ONE{public object i { get; set; }public ONE(){i = typeof(T).ToString();}public object make(int ix){ if (ix == 0) return i;ONE> x = new ONE>();/*dynamic x = new ONE>();*/return x.make(ix - 1);}}ONE x = new ONE();string lucky;Stopwatch sw = new Stopwatch();sw.Start();lucky = (string)x.make(500);sw.Stop();Trace.WriteLine(sw.ElapsedMilliseconds);Trace.WriteLine(lucky);` – Brian Sep 20 '11 at 20:04
  • 1
    Be fair to reflection and create a delegate from the method info: `var methodDelegate = (Action)method.CreateDelegate(typeof(Action), foo);` – Johnbot Oct 15 '15 at 15:42