C# 4.0 New Features Part 1 – dynamic keyword

by Justin Etheredge on October 28, 2008

This post was migrated from Justin’s personal blog, 'Codethinked.com.' Views, opinions, and colorful expressions should be taken in context, and do not necessarily represent those of Simple Thread (and were written under the influence of dangerous levels of caffeination).

One of the coolest new features in C# 4.0 that has been announced at PDC is the new dynamic keyword. This keyword allows the developer to declare an object whose method calls will be resolved at runtime. The interesting part about it is that the class doesn’t need to be declared in any special way to use this keyword, it is all up to the consumer.

Okay, so nothing changed, right? Wrong. Everything builds just as before, but now those method calls on our test method are not being resolved at compile time, they are being resolved at runtime! So, say we did this:

So this is what our main method looks like when we reflect it. It may be hard to follow, but make sure you look at the line numbers on the side to see where the wrapping occurs. First the compiler generated the “__SiteContainer0” local field in order to hold our callsite info. Next you will see that our “test” variable is just of class “object” now! There really isn’t a dynamic type, it is just a helper.

Next you see that we are checking if these callsites are null, and if they are, then we are using “CallSite.Create” and passing in a “CSharpCallPayload” object which has all the info about the method that we are trying to call. Once the callsite is defined, then we just invoke that callsite on our “test” instance by passing the callsite data and the object. The compiler has done all of this for us, we just need to sit back and let it happen.

So, in this instance what we are doing is pretty useless, but the power of this feature comes in when we are using a type whose methods we do not necessarily know at compile time. This could be because it is coming from some dynamic code (like IronRuby!), or it is a generated class that we don’t have compile time type info for, or anywhere that you are currently using heavy reflection for.

So, the first thing that popped into my mind when I saw this was, “what are the performance implications of this?” I know that this is a super early CTP, but I figured that I would run a few unscientific tests anyways.

So, here is the highly scientific process I used:

I changed to Release build and I put the two method calls in a loop surrounded by a stopwatch. The loop ran 1 million times, and so invoked a total of 2 million method calls. I then wrote out the number of milliseconds it took to execute to the screen. I also modified the TestClass to not write to the screen, since that would take significantly more time than the method calls. Instead, I changed the class to just add numbers, like this:

Now, this is a super early CTP and they will obviously optimize this, but they still are probably going to be many times slower than the compile time calls. The thing to realize here is that while these numbers are very different, we are still talking about 2 million calls in about 2 seconds. So, about one thousandth of a millisecond per call.

In most applications we are using reflection because we have to, or because it solves a problem that would be much harder to solve with strongly typed code. The overhead of making these kinds of calls is small, and unless they are being called with extremely high frequency would likely not make a noticeable impact on your application.

I hope that you enjoyed this quick little spin around the dynamic keyword, and I’ll be sure to come back shortly with more C# 4.0 goodies!

Thankyou for the pretty clear and nice post.
The best and most important part is (IMHO) the one related to the performance comparision, a thing that unfortunately too many bloggers leave uncovered in their coding-posts.
I hope to see more examples like this in the future 🙂

"var" represents a statically typed variable whose actual type has been inferred by the compiler. "dynamic" represents a dynamically typed variable whose actual type is completely unknown to the compiler, so all the calls it generates against the variable use late-bound dispatch.

where both classes have TestMethod1 defined.
Then, <Main>o__SiteContainer0.<>p__Site1 would be defined after the first call, and would be calling a wrong function after setting the dynamic variable to a different value.
Of course, I haven’t seen or installed the CTP so I wouldn’t know the exact implications.

ozone, the difference is that var is still bound at compile time. the line
var test = new TestClass1();
is translated into
TestClass1 test = new TestClass1();
You can see that using reflector.
However, dynamic is translated to object, and changes every usage of that variable, as seen in the example given by Justin.