Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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

3 Answers 3

up vote 12 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?

share|improve this answer
    
Or dynamic - apparently an order of magnitude faster than reflection. –  Oded Apr 5 '12 at 19:16
    
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
2  
@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

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).

share|improve this answer
3  
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
1  
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
    
@Lord Tydus: sure, but the case you describe is the rare exception. –  Michael Borgwardt Apr 7 '12 at 7:59

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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