(Why) Is Reflection so expensive in .Net?

Answer 1

Who cares what other people think? If you have made an educated investigation into your options (including other approaches that don't require the technique you are investigating), and found it to be the right option, then use it.

http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.16

As for "what is going on under the hood," you seem to have part of the picture. There is also the fact that none of the linkage is hard-coded, it all must be looked up at runtime. This means no in-lining is possible, no compiler errors are created if you mistype a member name, and all members must be looked up using a string, with any associated string compare perf hits (which may or may not exist, depending on stuff like string interning, etc).

Edit:

Well, I guess this last part of my answer isn't necessarily correct. It largely depends exactly on how you use reflections. Profile! And if you come up with an alternative solution, profile that too. :)

Answer 2

There are several questions on SO that answer this in a variety of ways.

Here's a good one IMO: http://stackoverflow.com/questions/224232/what-is-the-cost-of-reflection

One of the articles the answerer links gives some interesting info on certain functions of reflection being more costly than others. For instance, doing a typeof isn't too bad, but invoking methods is more costly.

Answer 3

The best answer is that the generally accepted mantra is not as simple as it seems. reflection == bad performance largely originated with .NET 1.0 and 1.1, and fails to acknowledge the performance improvements in later versions.

To be objective I've tested reflection-based solutions versus non-reflection based solutions on a number of occasions--and the winner isn't always one or the other. Reflection is what it is and it works how it works, it's not consistenly faster or slower and it (as with basically all programming approaches) can't be treated as a silver-bullet or as something to always be avoided.

Answer 4

There is a great deal of misconception around concerning reflection.

This guy has shown that a reflection takes approximately 3 times longer than a direct assignment. In reality, this feature used properly would not have a noticeable impact on performance. There's nothing wrong with using reflections in the correct context.

Answer 5

There are some things you just can't do with statically. Use reflection when you need it. You probably already use it more than you realize.

I've done many performance tests and measurements for reflection vs static operations. Reflection has more work to do and is always slower. But that's okay. "Slower" doesn't mean "slow", it just means "not as fast". That's how it should be considered. Reflection can still be fast, just not as fast as a static operation. It should not be automatically shunned because of this.

I've worked for lead developers who absolutely prohibited any reflective code in a web project because it would be slow. But it never seemed to occur to him that we were using NHibernate, ASP.NET and ASP.NET MVC data binding, all of which work almost exclusively with reflective data binding.

That person's aversion to reflection was irrational and unfounded. I think this is the case with a LOT of people you talk to about it.