What is the "cost" of reflection?

Question

I am currently in a programming mentality that Reflection is my best friend. I use it a lot for dynamic loading of content that allows "loose implementation" rather than strict interfaces, as well as a lot of custom attributes.

The question I have is, what is the "real" cost to using reflection?

Is it worth the effort for frequently reflected types to have cached reflection, such as our own pre-Linq DAL object code on all the properties to table definitions?

Would the caching memory footprint outwieght the reflection cpu usage?

Thanks!

Answer 1

Reflection requires a large amount of the type metadata to be loaded and then processed. This can result in a larger memory overhead and slower execution. According to this article property modification is about 2.5x-3x slower and method invocation is 3.5x-4x slower.

Here is an excellent MSDN article outlining how to make reflection faster and where the overhead is. I highly recommend reading if you want to learn more.

There is also an element of complexity that reflection can add to the code that makes it substantially more confusing and hence difficult to work with. Some people, like Scott Hanselman believe that by using reflection you often make more problems than you solve. This is especially the case if your teams is mostly junior devs.

You may be better off looking into the DLR (Dynamic Language Runtime) if you need alot of dynamic behaviour. With the new changes coming in .NET 4.0 you may want to see if you can incorporate some of it into your solution. The added support for dynamic from VB and C# make using dynamic code very elegant and creating your own dynamic objects fairly straight forward.

Good luck.

EDIT: I did some more poking around Scott's site and found this podcast on reflection. I have not listened to it but it might be worth while.

Answer 2

With great power comes great responsibility.

As you say, reflection has costs associated with it, and depending on how much reflection you do it can slow the application down significantly.

One of the very approrpiate places to use it is for IoC (Inversion of Control) since, depending on the size of your application, would probably have more benefits than not.

Answer 3

Thanks for the great links and great comments, especially on the part of the Jr Devs, that hit it right on the money.

For us it is easier for our Jr Devs to do this:

[TableName("Table")]
public class SomeDal : BaseDal
{
    [FieldName("Field")]
    public string Field
}

rather then some larger impelementations of DAL, this speeds up thier building of the DAL objects, while hiding all the internal workings for the Sr Devs to gut out.

Too bad LINQ didn't come out earlier, I feel at times we wrote half of it.

Answer 4

Please go to CodeProject and search for LinFu (or just Google it). Its a set of development libraries to make lots of tasks in .NET faster and easier. But included in it is a class called DynamicProxy. The article that goes along with it explains in great detail the precise performance implications of different types of reflection operations. Some are more expensive than others.

Also, check out CGLib at sourceforge, as it provides some code generation libraries to speed up many reflection tasks.

Answer 5

There are lots of things you can do to speed up reflection. For example, if you are doing lots of property-access, then HyperDescriptor might be useful.

If you are doing a lot of method-invoke, then you can cache methods to typed delegates using Delegate.CreateDelegate - this then does the type-checking etc only once (during CreateDelegate).

If you are doing a lot of object construction, then Delegate.CreateDelegate won't help (you can't use it on a constructor) - but (in 3.5) Expression can be used to do this, again compiling to a typed delegate.

So yes: reflection is slow, but you can optimize it without too much pain.

Answer 6

One thing that can sometimes bite you when using reflection is not updating calls using reflection when doing refactoring. Tools like resharper will prompt you to update comments and strings when you change a method name, so you can catch most of them that way, but when you're calling methods that have been dynamically generated or the method name has been dynamically generated you might miss something.

The only solution is good documentation and thorough unit testing.