13

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?

Community
  • 1
  • 1
Manu
  • 28,753
  • 28
  • 75
  • 83

5 Answers5

12

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.

STW
  • 44,917
  • 17
  • 105
  • 161
  • This is exactly my experience. – Preet Sangha Aug 02 '10 at 21:31
  • +1, since this reflects genuine (anecdotal) experience with this technology. – Merlyn Morgan-Graham Aug 02 '10 at 21:36
  • 1
    I'd be interested in seeing a case where reflection is faster than direct access... from my experience, it's always much slower. Could you give an example to illustrate such a case ? – Thomas Levesque Aug 02 '10 at 22:34
  • @Thomas: It's not a question of whether reflection is faster or slower than direct access (of course it's going to be slower) but you would never use reflection where direct access was possible anyway. For a real-world example, compare serialization with reflection vs. serialization by implementing `ISerializable` directly (factor in the cost of *implementing* `ISerializable` as well, and it'll never be a straight-up comparison). – Dean Harding Aug 03 '10 at 05:41
3

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

Merlyn Morgan-Graham
  • 58,163
  • 16
  • 128
  • 183
  • 1
    This question is an attempt to form an educated opinion. If I had one already, I would not have to ask. – Manu Aug 02 '10 at 21:27
  • 1
    @Manu: Great to hear it :) I don't mean to scold you, I mean to give you ammo to shield yourself from what everyone else says you should do, especially if they don't intimately know your requirements, and haven't done this investigation themselves. Many people give in to this pressure. – Merlyn Morgan-Graham Aug 02 '10 at 21:29
  • @Manu: Also, there's the standard "profile, then optimize" recommendation. If your perf hits your customer requirement guided perf budget, who cares what implementation you use. – Merlyn Morgan-Graham Aug 02 '10 at 21:32
3

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.

Community
  • 1
  • 1
pinkeerach
  • 408
  • 9
  • 19
3

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.

Phil Gilmore
  • 1,286
  • 8
  • 15
2

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.

Nobody
  • 4,731
  • 7
  • 36
  • 65