Is reflection really THAT slow that I shouldn't use it when it makes sense to?

Question

The "elegant" solution to a problem I am having is to use attributes to associate a class and its properties with another's. The problem is, to convert it to the other, I'd have to use reflection. I am considering it for a server-side app that will be hosted on the cloud.

I've heard many rumblings of "reflection is slow, don't use it," how slow is slow? Is it so CPU intensive that it'll multiply my CPU time so much that I'll literally be paying for my decision to use reflection at the bottom of my architecture on the cloud?

Answer 1

Probably you won't even notice it. Always profile first before thinking about optimizations.

Answer 2

It's many times faster than filesystem access.

It's many many times faster than database access across the network.

It's many many many times faster than sending an HTTP response to the browser.

Answer 3

I've wondered the same thing; but it turns out that reflection isn't all that bad. I can't find the resources (I'll try to list them when I find them), but I think I remember reading that it was maybe 2x to 3x slower. 50% or 33% of fast is still fast.

Also, I under the hood ASP.net webforms and MVC do a bunch of reflection, so how slow can it really be?

EDIT

Here is one resource I remember reading: .Net Reflection and Performance

Answer 4

Just in case you don't see the update on the original question: when you are reflecting to find all the types that support a certain attribute, you have a perfect opportunity to use caching. That means you don't have to use reflection more than once at runtime.

To answer the general question, reflection is slower than raw compiled method calls, but it's much, much faster than accessing a database or the file system, and practically all web servers do those things all the time.

Answer 5

Hmm, I try to avoid reflection if I can, but if I have to create a solution, and reflection gives me an elegant way to solve problem at hand, I 'll hapily use reflection.

But, it must be told that I think reflection should not be used to do 'dirty tricks'. At this very moment, I'm also working on a solution where I use custom attributes to decorate some classes, and yes, I'll have to use reflection in order to know whether a class / property / whatever has been decorated by my custom attribute.

I also think it is a matter of 'how much do you make reflection calls' ? If I can, I try to cache my results. Like, in the solution where I'm working on: on application startup, I inspect certain types in a certain assembly, whether those types have been decorated with my attribute, and, I keep them in a dictionary.