How does having a dynamic variable affect performance?

Question

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));
    }

Solution 1

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?

Solution 2

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:

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.

Comments

[user1703401]

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.

[nawfal]

also see stackoverflow.com/questions/3784317/…

[Sergey Sirotkin]

Such a detailed response, thanks! I was wondering about the actual numbers as well.

[Eric Lippert]

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]

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.

[Roman Royter]

Just out of curiosity, the special compiler version without parser/lexer is invoked by passing a special flag to the standard csc.exe?

[StriplingWarrior]

@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.

[Adam Rackis]

@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.

[Eric Lippert]

@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]

@Adam: I think you are thinking of this one: blogs.msdn.com/b/ericlippert/archive/2009/03/19/…

[ShuggyCoUk]

@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 :)

[Eric Lippert]

@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.

[Brian]

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<T>{public object i { get; set; }public ONE(){i = typeof(T).ToString();}public object make(int ix){ if (ix == 0) return i;ONE<ONE<T>> x = new ONE<ONE<T>>();/*dynamic x = new ONE<ONE<T>>();*/return x.make(ix - 1);}}ONE<END> x = new ONE<END>();string lucky;Stopwatch sw = new Stopwatch();sw.Start();lucky = (string)x.make(500);sw.Stop();Trace.WriteLine(sw.ElapsedMill‌​iseconds);Trace.Writ‌​eLine(lucky);

[configurator]

Or an IDynamicMetaObjectProvider?

[Sergiy Belozorov]

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?

[Asad Saeeduddin]

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?

[Eric Lippert]

@AsadSaeeduddin: If the receiver is of the same type then how can the method Foo resolve to a different method?

[Johnbot]

Be fair to reflection and create a delegate from the method info: var methodDelegate = (Action)method.CreateDelegate(typeof(Action), foo);

[l33t]

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<T> : DynamicObject have 100 call sites for every T, or worse?

[Eric Lippert]

@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.

[Nikola Malešević]

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)?

[Eric Lippert]

@NikolaMalešević: The cache is a dictionary. Sorry if I implied it was not; that was not my intention.

[Eric Lippert]

@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.

[Thomas Darling]

@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]

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 github.com/dotnet/runtime/issues/18655