Is Reflection really slow?

Question

This is a common belief that reflection is slow and try to avoid it as much as possible. But is that belief true, in the current situation? There has been lot of changes in the current .net versions like, use of IL Weaving (i.e. IL Emit) etc, as opposed to traditional PropertyInfo and MethodInfo ways of performing reflection.

Is that any convincing proof, that the new reflection is not that slow any more, and can be used. Is there better way to read attribute data?

Thanks, Bhaskar

Answer 1

When you think about it, reflection is pretty darn impressive in how fast it is.

A cached delegate from a ConstructorInfo or MethodInfo can be called with speed comparable to any other delegate.

A delegate created from ILGenerator.Emit (which incidentally isn't new, it's been in .NET since version 1) can likewise be called just as fast.

An object obtained through emitting or calling a ConstructorInfo's delegate will be just as fast as any other object.

If you obtain an object by loading an assembly dynamically, using reflection to find the method to call, and calling it, and it implements a defined interface through which you call it from that point on, then it'll be just as fast in how it's used as another implementation of that interface.

In all, reflection gives us ways of doing things that without it we would - if we could do them at all - have to use techniques that are slower both to code and to execute.

It also gives us means of doing things that are more complicated, more brittle, less type-safe and less performant than other means too. Pretty much every line of C# code can be replaced by a big chunk of code that uses reflection. This code will almost certainly be worse than the original line in a whole bunch of ways, and performance is the least of them.

Quite possibly the "avoid reflection because its slow" advice stems from the belief that the sort of developer that would go nuts for any new technique just because it seemed cool would be the sort that would be more likely warned off by "it'll be slower" than by "it'll be less idiomatic, more error-prone and harder to maintain". Quite possibly this belief is completely correct.

For the most part though, when the most natural and obvious approach is to use reflection, then it also won't be less performant than a really convoluted attempt to avoid it.

If performance concerns apply to anything in reflection, its really to the uses that are hidden:

Using dynamic can seem sensible in a case where only a little work could avoid it. Here the performance difference may be worth considering.

In ASP.NET, using <%#DataBinder.Eval(Container.DataItem, "SomeProperty")%> is easier but generally less performant than <#((SomeType)Container.DataItem).SomeProperty%> or <%#SomeCodeBehindProvidedCallWithTheSameResult%>. I'll still use the former 90% of the time, and the latter only if I really care about a given page's performance or more likely because doing many operations on the same object makes the latter actually more natural.

So in all, everything remains "slow" in computers while they are bounded by the requirement to work in a single universe in a way that consumes energy and takes time, for some value of "slow". Different reflection techniques have different costs, but so does the alternatives. Beware not so much of reflection in cases where it's the obvious approach as hidden reflection where another approach just slightly less obvious may serve well.

And of course, code wisely with whatever technique you use. If you're going to call the same delegate a hundred times in a row, you should be storing it rather than obtaining it each call, and that would go whether the way to obtain it was through reflection or not.

Answer 2

It all depends.
Yes, using reflection is without any doubt slower than not using reflection, but you have to look at the big picture:

For example, imagine that your code does some reflection and then loads some data from a database over the network.
In this case, you can completely neglect the additional cost for reflection because the database request over the network will likely take much, much longer.