18

Possible Duplicate:
How costly is .NET reflection?

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?

Community
  • 1
  • 1
Professional Sounding Name
  • 1,090
  • 10
  • 25

5 Answers5

29

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.

Daniel Earwicker
  • 114,894
  • 38
  • 205
  • 284
  • 2
    +1 for caching the result. If you treat reflection just like reading the information from the filesystem then you won't go far wrong - do it, but not more often than you have to. – stevemegson Mar 05 '09 at 21:06
  • Yep Reflection then cache .. but certainly not worth it just for prettier code. – user1496062 Jan 25 '22 at 02:10
17

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.

yfeldblum
  • 65,165
  • 12
  • 129
  • 169
  • Yes and no .. Reflection calls Assembly load and parse sometimes when its not in its cache and IIRC its cache is 16 types ( so be warned about micro benchmarks unless you tests lots of types) this is very slow much slower than a http or network call . Removing Automapper has made huge reduction in call times especially perc95 times in a number of projects. – user1496062 Jan 25 '22 at 02:13
8

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

Esko Luontola
  • 73,184
  • 17
  • 117
  • 128
4

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

Giovanni Galbo
  • 12,963
  • 13
  • 59
  • 78
  • Very hard tp benchmark but i measure noticable differences when not using it IIRC its cache is 16 types so be warned about micro benchmarks unless you tests lots of types. Remember json serialization , Automapper all fight for this cache. – user1496062 Jan 25 '22 at 02:15
4

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.

Frederik Gheysels
  • 56,135
  • 11
  • 101
  • 154