Many of you might have heard, calling reflection APIs from your code is always slower than that of calling it directly. Well, it is right. Some of the major Reflection methods like GetXXX (of MethodInfo, PropertyInfo, FieldInfo etc) are say 100 times slower than that of calling a Method, Property or Fields directly. In this post, I will try to cover some of the major portion of Reflection which is slower like hell than that of normal method call and also try to solve the same.

So what is Reflection for?

As I have already told you about Reflection and Code Emit and also how to build your Lamda Expression Tree, it is good to know where you would like to use Reflection. Yes... Reflection is made truly late bound approach to browse through the object hierarchy or to call methods inside the object. So if you do not know much about your object hierarchy or you have somehow found an assembly external to your application and you need to parse through the object and call its methods say, then Reflection would be the right choice for you.

So basically Reflection allows you to create plugin type of applications where you define an Interface and publish the same for your application and let others create those plugins for you to seamlessly added to your application. Fine. Then what it isn't for?

Yes basically few people try to work everything based on Reflection. Using reflection unnecessarily will let your application very costly. Say for instance,

Silly huh..
I saw few people to do this. They try to use everything using Reflection, may be they love the Reflection too much, or they have already created a Reflection engine right and do not want to mix up unknown types with known ones. May be they would make their code clear by calling the known types to the same module that is built up for dealing with unknown types.

These things go really worse when you do these reflection calls in a loop.Say for instance, you are about to set 100 of members of an object at runtime and use say PropertyInfo to deal with these 100 setters. Yes, the code will look very simple but at a performance cost.

Type.InvokeMember is often very slow as well as Activator.CreateInstance, when there are large number of Members in a type of there are large number of Types in an assembly. Yes, going truly late bound with these will make your application real slow.

Where should you avoid Reflection ?

Yes this is the general question for everyone. Reflection works very well when you know the object. The more you know about the object, the more you can avoid going searching the object hierarchy. One of the most costliest method I have found is GetCustomAttributes, where you are trying to find an attribute from a type, whether it is added or not to do something with the types. If you don't know where the Custom attributes to be set to or say you have AttributeTargets.All set to the attribute and you use
myassembly.GetCustomAttributes(true)

The additional parameter true means it will go through all the Types, its methods, its properties and try to find your attribute. Hence its a call to traverse the whole object hierarchy. Yes, this is horribly costly. You must avoid these calls. Let me list some of the costly methods on Reflection :

GetCustomAttributes

GetXX ( PropertyInfo, MethodInfo, EventInfo, FieldInfo etc)

Type.InvokeMember (when Type is very big)

Activator.CreateInstance

There are others too. But you should always try to avoid these methods call in a loop.

Reflection and ASP.NET websites

When it comes with the notion of ASP.NET websites, we always think of dealing with performance and throughput. For ASP.NET sites, it is better to avoid excessive usage of Reflection, may be when you use Reflection for every call to invoke a member which is plugged in to your application, it would make your application work slower and slower when you have thousands of calls to your application. This is the problem with DasBlog which actually have used Reflection to deal with each blog posted. Hanselman pointed out the issue for them, as it tries to find out each member using Reflection. The performance of the site increased 100 times just by changing these things.
Yes, if your Web application needs to perform well in stressed condition, I should say you should think twice before using Reflection at your end. Rather it would be lightening fast if you didn't have used Reflection to deal every step.

How slow Reflection is?

Yes, now its time to deal with Reflection against real time data. As Reflection is truly late bound approach to work with your types, the more Types you have for your single assembly the more slow you go on. Let me try to demonstrate with you how slow the performance is by taking an example of a large dll (with 100s of types associated with it) and try to invoke a member on it using Reflection and without it and measure the performance boost you have.

Eric Gunnerson also employed a lot of effort around measuring the few methods himself. In his article(sorry it isnt available), he demonstrated based on his 100,000 call to a single method in .NET framework 1.1 gives him a result like :

So according to him, Type.InvokeMember and DynamicMethod.Invoke takes the longest time to run. MethodBase.Invoke ( or MethodInfo.Invoke) is half in performance, DynamicMethod.Delege will take even lesser time, next is normal delegate call, finally the interface call and IL based instructions. Fairly smart enough? Probably, but lets build our own application to demonstrate these scenario.

Let me take an example of a simple class,(I call it as DummyClass) which has only 1 method in it named CallMe inside a DummyNamespace on a large assembly with 547 Types.So the class looks like :

Looks simple huh.. Well, lets create a consumer class to check how it performs in stressed situations. I will create objects of DummyClass in a loop and call CallMe with random values in both using Reflection API and normally. To do this, I create a class ReflectionCalculator with few methods.

So if you look into these two calls, viz ReflectionBasedCall and NormalCall, you could see, definitely both are doing the same thing. I have placed a Assembly object outside so that I could check only the logic to call a method. The Reflection approach needs to first Get a Type using Assembly.GetType, which eventually searches the entire object hierarchy and then GetMethod, which finds on the Type. Hence the bigger the size of the assembly, the slower these work. Finally the Activator.CreateInstance which actually creates the instance of the object. While the other is doing the same thing normally. Now if say I call both the methods 100000 times using this code and print out the time in milliseconds, it will look like :

So here, we cache each objects in its respective properties. So, it might relax our head a bit, but mind that, this could not be the situation of you that you can the same method every time. But to see how fast method Invoke works lets run the code.

So the time consumed abruptly decreased due to caching applied on it. So basically most of the time was taken by GetType and GetMethod and even with Activator.CreateInstance. But if you see the result it is still 15 times the normal call.

Using an Interface

Interface works great in these situations. Lets take an Interface which is present in both the dlls where the DummyClass actually implements the interface IDummy. OMG, interface works so well in these situations. If you have everything cached, it works the same like normal calling instructions.

You must be amazed to see this. Yes, it actually works better in this situation that of normal IL instructions.

But no.. Its actually not. Basically calling a light weight interface is better than calling a concrete object from architectural point of view. If you make the caching of IDummy for a moment and compare you will see the difference. Holding Cached object and calling through its interface is better in performance than that of the normal calls. So lets change our code a bit and see :

Yes rightly so, Interface will not work better than raw IL instructions. But is it possible to have Interface for everything we call? You are right, it would put a lot of effort if you need to have interface for every single Reflection call. So probably its time to think something else.

Lets use Dynamic Delegates

Well another or probably best approach I found is the use of dynamically created delegates based on signature of MethodInfo, PropertyInfo objects. Using Dynamic flexibility of C# language or creating dynamic delegate at runtime will make the Reflection code very fast.

Basically the idea is to build Generic delegates for each type of MethodInfo we need to call and eventually store the same into some in memory cache. This way, you just need to build some Action or Func delegates for your calls (based on the signature) and on every call to them, you can maintain a list where you store each delegate with the MethodInfo. Hence for the next time, when you require to invoke the same Method, you could use the delegate directly.

To do this, I have used System.Linq.Expressions. If you are new to Dynamic feature using Expression Tree, you can try my post to grab the concept. I have used Expression as it seems better for me, but you could also use System.Reflection.Emit to build these call wrappers.

To use this, I have created a few extension methods for properties, methods etc. Lets take the example of MethodInfo in our case.

So eventually I am using this Lambda expression to build an Action<object,T> where object represents the instance of the class for which we are going to execute the method and T represents the Type argument in the argument list.

If you see the code above cautiously, you could understand that I am building a lambda like :

(x, y) => return x.[method](y)

So using the Caching as well here, lets dynamically build our delegate object using the code:

So basically, I have build an delegate object with MethodCallDelegate and also cached the same for every call of the method. The MethodCallDelegate actually invokes the extension method CallMethod from CachedMethodInfo object and stores it into a variable.

Note : In your real time application, when you require to create a large number of Reflection calls, cache MethodDelegate in a collection with MethodInfo objects, so that you could try to find the same from the collection instead of creating the Dynamic method each time you call.

Now to demonstrate this lets put another section in our program to call this CacheBasedDelegateCall. Hence the output will look like :

OMG, it works great with this approach. Yes, if you can leverage out the time taken to dynamically compile the application, then the application will work as fast as before.

Blog Subscription

Learn MVC 5 step by step

My friend Shivprasad Koirala who is also a Microsoft ASP.NET MVP has released Learn MVC 5 step by step video series. It starts right from basics of MVC and goes to a level until you become a professional.
You can start taking the course for free using the below youtube video.
Please try it, you will find it awesome.

My Awards

Hit Counter

Twitter

Best .NET 4.5 Expert CookBook

Abhishek authored one of the best selling book of .NET. It covers ASP.NET, WPF, Windows 8, Threading, Memory Management, Internals, Visual Studio, HTML5, JQuery and many more...
Grab it now !!!
Another book on .NET 4.5 has been released very recently. It covers Debugging, Testing, Extensibility, WCF, Windows Phone, Windows Azure and many more...
Grab it now !!!GET ANY BOOK AT $5 from PacktPub. Offer is limited