(Why) Is Reflection so expensive in .Net? [duplicate]_问答_开发者

This question already has answers here: 开发者_如何学JAVA Closed 12 years ago.

Possible Duplicate:
What is the “cost” of reflection?

Does anyone have a good explanation of the generally accepted mantra that reflection == bad performance?

For example, how expensive is it to iterate over a type's properties collection and extract all property values from an instance of this type compared to just accessing all the properties directly? One level of magnitude? Two? What does it depend on? Is it predictable at all? What is happening under the hood?

EDIT: Thanks for the answers so far. I've looked into some the links you provided and it seems that there is a vast gap of estimates out there regarding Reflection on Properties compared to direct access: from 2.5 times slower to 200 times slower.

This does not seem very reasonable to me. Some of you mentioned performance improvements in later versions of .Net so let be narrow my question to .Net 4.0. Does anyone have any benchmarks for that?

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.

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

Here's a good one IMO: What is the "cost" of .NET 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.

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

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.

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.