Newbie C# Question - Reflection is slooooooooow?

[Guest]

Thanks to some great comments, I was able to get this code to work:

// Dynamically load the DLL
string sDLLName = "C:\\Test\\Test2.dll";
sDLLName = "..\\bin\\Test2.dll";
Assembly objAssembly = System.Reflection.Assembly.LoadFrom(sDLLName);

// Create an instance of the class
object testObject = objAssembly.CreateInstance("Test2.Test");

// Call the method "TestMessage" which has one argument
object[] object2 = new object[1];
object2[0] = 200;

MethodInfo Method = testObject.GetType().GetMethod("TestMessage");
object result = Method.Invoke(testObject, object2);

// This should return 300 and does
Console.WriteLine(result.ToString());

BUT reading a blog, there was an interesting comment made:

8. Reflection is slooooooooow

Relfection can be great if you use it with care. Late binding looks as it is
a holy grail for software extensibility (and yes it is, as I explained in a
post on my blog earlier). If you use late binding (e.g. when loading
"providers" from a configuration file using reflection), make sure you can
cache the retrieve object instance to avoid a second binding performance hit
(caused by Activator.CreateInstance for example).

My question is: how do you cache the object? Is that referring to the object
being “global†to the code so you are not loading it every time, or is there
a mechanism for handling caching of a late-bound DLL? I am trying to clarify
the comment.

Thanks so much!
Michael

 

[Patrice]

AFAIK yes. The basic idea is that if you need the object several times keep
a reference to it rather than creating it several times.
If not already done measure. It's slow but if you do this rarely the time
taken to optimize this could likely be spent elsewhere with more profit.
Finally IMO providers are most often not really late binded. Instead they
implement a particular interface. It allows to guarantee that the class
implements a particular set of members allowing likely at compile time to do
some optimization (measure the difference...)

Patrice

 

[Eric]

Benchmark it in your own application before you assume it will be too
slow. Don't spend hours fixing it until you determine how slow it is in
your application.

 

[Guest]

Every powerfull tool is slow ;-)

The dynamic invocations of ctor, method, properties, etc are the slowest
functionalities of Reflection. You don’t want to do that in a loop or
something :-/

It is safe enough to "CreateInstance" an object once, keep the reference,
and use it like a class factory or interface provider (anything you want).

The only unbearable slowness I have experimented is due to the underlying
implementation of both Reflection.Cache (a private framework object that
already deals with the caching of the various a-little-slow MemberInfo’s) and
the underlying unmanaged code it uses (event more memory hungry that the dumb
Reflection.Cache).
But you won’t notice this bug until you dynamically invoke a lot (> 10000)
of *different* classes/method…