I've noticed when dealing with Expressions or Expression Trees I'm using reflection a lot to set and get values in properties and what have you. It has occurred to me that the use of reflection seems to be getting more and more common. Things like DataAnotations for validation, Attribute heavy ORMs, etc. Have me wondering: What has changed since the days years and years ago when I used to be told to avoid reflection if at all possible?

So what, if anything has changed? Is it just the speed of the machines? Have there been changes to the framework to speed up reflection?

Or has nothing really changed? Is it still "bad" or "slow" to use reflection?

  • 2
    Reflection will always be slower than direct calls, because you have to perform several steps to find and verify that what you're calling exists. – Michael K Apr 5 '12 at 19:26
  • It was always bad....Of course sometimes you have no choice, its up to the programmer to know when those times are, and avoid it otherwise. – Ramhound Apr 6 '12 at 13:57
  • Performing a Reflection with gettype to pull one item in an enum is still over 30 times faster than throwing an exception with Enum.Parse( ). So reflection wins sometimes. – Brain2000 Apr 13 at 19:53
up vote 16 down vote accepted

Reflection is neither bad, nor slow. It is simply a tool. Like all tools, it is very valuable for certain scenarios, not so valuable for others.

If performance is really an issue, you can always use a library like FasterFlect.

Further Reading
If reflection is inefficient, when is it most appropriate?

  • Or dynamic - apparently an order of magnitude faster than reflection. – Oded Apr 5 '12 at 19:16
  • 1
    Performance isn't an issue at all. I just vividly remember people avoiding reflection back in 2002 like it was the plague. I'm wondering what's changed since then. – blesh Apr 5 '12 at 19:17
  • 3
    @blesh: Nothing. People are more familiar with it now, and less afraid of it. – Robert Harvey Apr 5 '12 at 19:18
  • 5
    I could be all "get off my lawn" here and say that Lisp had this long before OOP existed... – Michael K Apr 5 '12 at 19:19
  • Fair enough. I was just wondering if it was the speed increases in machines in the last ten years that has made the difference or if there were actually changes made to System.Reflection that have boosted performance. – blesh Apr 5 '12 at 19:22

The reason people are wary of using reflection unnecessarily is not performance: yes, there is some overhead to using reflection, but often, solving the problem without it requires a different approach with comparable complexity, and even if it doesn't, the overhead is seldom significant (especially for application-level development).

Using reflection, some important assumptions one can normally make about source code are broken, and tools such as "Find All References" cease to work reliably. Reflection also basically removes most of the type safety the compiler enforces in, say, C#, and most of the programming errors that a type system would normally catch and translate into compiler errors, now become runtime errors at best or very obscure bugs at worst.

So why do people use reflection then? Simply put, because despite the problems described above, it is a very valuable tool. With reflection, some of the benefits of dynamic programming can be had in a static, strictly-typed language like C#, and dynamic programming languages have shown their merits recently, especially in the realm of web programming - PHP, Javascript, and quite prominently Python, all use dynamic typing, and have proven to be good fits for web programming. But since the language is still C#, you can choose to keep most of your application in a strictly-typed OOP idiom, and write the small part where dynamic behaviour really makes a difference with reflection.

A typical example is when you need to expose methods as web service calls (using a protocol not yet built into .NET). The strictly-typed OOP approach does work, but it is overly restrictive and clumsy. But if you use reflection to map calls to methods and key/value pairs to arguments, you can write the plumbing for such a web service once and then use it on any class you like.

Reflection is still significantly slower than direct calls. Two things have changed:

  • Runtimes have optimized reflection mechanisms so that the difference has become smaller
  • CPUs have gotten faster so that small inefficiencies are easier to tolerate

Together, these two factors have brought the cost of reflection down to the point where you can routinely use it (where appropriate from a maintainability POV) and wait for the profiler to tell you whether it's actually a bottleneck (and be reasonably sure that most of the time it won't be).

  • 4
    alas, CPUs have become slower - typically on mobile devices, and the server where people are trying to squeeze as much efficiency out of their servers as possible due to the costs of running them. – gbjbaanb Apr 6 '12 at 1:32
  • @gbjbaanb: I'll give you mobile devices, but on the server, buying more hardware rather than optimizing the code is the accepted and rational choice in the vast majority of cases, because the costs of buying and running servers are so much lower than the costs of optimizing code. – Michael Borgwardt Apr 6 '12 at 23:48
  • 2
    In some situations the server costs dramatically outweigh the development costs. In large scale-out style. Even though servers are buff, performance can be even more critical than on a client machine. It's a case by case scenario. – Lord Tydus Apr 7 '12 at 2:33
  • 1
    @Lord Tydus: sure, but the case you describe is the rare exception. – Michael Borgwardt Apr 7 '12 at 7:59

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.