A related post here pretty much established reflection in Java as a performance hog. Does that apply to the CLR as well? (C#, VB.NET, etc).
EDIT: How does the CLR compare to Java when it comes to reflection? Was that ever benchmarked?
A:
Yeah, reflection in .NET is a performance intensive operation too as it requires querying metadata tables in assemblies.
Mehrdad Afshari
2009-01-13 19:24:20
Is that still true even after the assemblies are loaded in memory?
Otávio Décio
2009-01-13 19:25:10
Yes. Dynamically resolving types and members by name requires looking them up in the type system which is clearly slower than static resolution.
Mehrdad Afshari
2009-01-13 19:27:04
Yes it is, because even though the assemblies are in memory you must still look at the metadata tables which is the slow part.
Andrew Hare
2009-01-13 19:27:19
Related question - was that ever benchmarked?
Otávio Décio
2009-01-13 19:27:55
Also... how does the CLR compare to Java when it comes to reflection?
Otávio Décio
2009-01-13 19:28:55
It's very easy to see it's MUCH slower by a simple code snippet. Similar to the one you linked for Java. However it's really a runtime dependent thing. You should benchmark against a specific version of Java runtime and .NET runtime.
Mehrdad Afshari
2009-01-13 19:30:31
A:
The default implementation of Equals for value types is implemented using Reflection. It works, but it is darn slow and it is easy to implement a specific version, which is much faster (the catch is that you have to implement GetHashCode as well). How much faster depends on the actual value type of course, but I have seen some huge boosts here.
Brian Rasmussen
2009-01-13 19:31:45
+2
A:
I wouldn't really care about the instantiation performance of the object using reflection itself but the actual performance of methods and such since those are after all what I'll be using from the class anyway.
Surely the instantiation takes a lot of time as can be seen in the linked post but since you're most likely using the object's methods instead of just instantiating it, you shouldn't worry too much about reflection performance - as long as you're not doing the method calls by invoking reflected Method objects!
Besides you only need one reflected instance of the object, use .clone() and other clever tricks if you need to create more copies.
Esko
2009-01-13 19:50:58
What if you are using reflection as part of your logic - not necessarily instantiating anything but using your type definition as a guide - sort of "meta-programming" ?
Otávio Décio
2009-01-13 19:53:30
If you're not instantiating objects, why would you want to reflect (parts of) them anyway? I'd be interested to see an example of what you exactly mean though, if you have time please explain in more detail.
Esko
2009-01-13 19:55:40
Suppose you have a list of objects and want to edit their values. Through reflection you could build a single user interface that would allow you to do that. You can define attributes for the labels, max size, etc.
Otávio Décio
2009-01-13 19:57:47
Ah, valid case of such behavior and now I understand what you mean. Yeah, that's unfortunately slow but if I remember correctly (a bit hazy here) it is possible to create a proxy object using java.lang.reflect.Proxy for speeding up such functionality by reusing the proxy for every object in list.
Esko
2009-01-13 20:05:41
I understand that in Java it is slow, but I'm curious if the same applies to C#.
Otávio Décio
2009-01-13 20:08:23