Performance of the dynamic keyword

In .NET 4.0 a new keyword was introduced: the dynamic keyword. One of the things it allows is calling methods on an instance and bypassing the compile time type checks. It can be useful in many scenarios, for example duck typing.
In this post, we’ll see that in some cases the keyword might have an unnecessary performance hit. Another thing we’ll see is how to save some of that time.

Simple performance measure

Let’s compare the performance of 3 ways of getting a property value – directly, using dynamic and using reflection:

public static string GetName(Student arg)
return arg.Name;
public static string GetNameByDynamic(dynamic arg)
return arg.Name;
public static string GetNameByReflection(object arg)
Type type = arg.GetType();

MethodInfo getter;
if (!typeToMethodMap.TryGetValue(type, out getter))
PropertyInfo property = type.GetProperty("Name");
getter = property.GetGetMethod();
typeToMethodMap.Add(type, getter);

return (string) getter.Invoke(arg, null);

Calling each method 10,000,000 times sums to: GetName=0.02 seconds, GetNameByDynamic=0.47 seconds, GetNameByReflection=15.41. Meaning, dynamic compared to strong type call is ~20 times slower.

Improving performance using interface

One way to deal with this performance hit is to extract an interface from all possible objects, through using it we can get back to work with strong type:

public interface INameProvider{
string Name { get; set; }

And change our method to:

public static string GetNameByInterface(INameProvider arg)
return arg.Name;

Luckily this code runs at 0.07 seconds, which is ~7 times faster than the dynamic version. The conclusion from this is that if our code is in a critical performance area, we better extract an interface (as long as it makes sense – don’t abuse the interface if the types have no logical commonality!).

Improving reflection version using expressions

What should we do if our code is written in pre-.NET 4.0 version and our solution is based on reflection? In this case, our code runs ~750 times slower than the strong type version. Since we can’t use dynamic, which was introduced first at .NET 4.0, we should find some other solution. A simple one is generating a method using expressions. The main advantage of expressions here is that they can be compiled into a new method which we can reuse.

public static string GetNameByExpression(object arg)
Type type = arg.GetType();

Func<object, string> getterDelegate;
if (!typeToDelegateMap.TryGetValue(type, out getterDelegate))
var parameterExpression = Expression.Parameter(typeof (object), "arg");
var castExpression = Expression.TypeAs(parameterExpression, type);
MemberExpression memberExpression = Expression.Property(castExpression, "Name");
var lambda = Expression.Lambda<Func<object, string>>(memberExpression, parameterExpression);

getterDelegate = lambda.Compile();
typeToDelegateMap.Add(type, getterDelegate);

return getterDelegate(arg);

This code here is basically equivalent to generating a lambda which looks like:

(object arg) => ((Student)arg).Name;

After we compile the code once we can skip the reflection invocation each time and end with much faster code. Running this method times 10,000,000 takes 0.86 seconds, which is ~18 times faster than the reflection solution.


If you are writing code which must run as fast as possible, this is the performance summary:

Seconds Ratio to directly
Directly 0.02 1
Through interface 0.07 3.5
Using dynamic 0.47 23.5
Using expression 0.86 43
Reflection 15.41 770

2 responses to “Performance of the dynamic keyword

  1. Hi,

    missing info about warmup behavior when measuring time? You should burn one itteration since I guess most will not just call once per appdomain right?

    Also, why not add IL to?



  2. Very good point about the warmup, here are the timings of each version:
    Directly = 00.0000164
    Interface = 00.0000527
    Dynamicly = 00.0536926
    Reflection = 00.0022585
    Expression = 00.0020478

    I was a little surprised that the dynamic warmup is ~20 times slower than compiling an expression, still studying what it does behind the scenes.

    The solution based on reflection emit will get its own post soon. Originally I wanted to post it here but the code is a little intimidating to those who don't speak IL 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s