views:

1794

answers:

6

I recently created an interface layer to distinguish the DataAccessProvider from our Business logic layer. With this approach we can change our choice of DataAccessProvider whenever we want by changing the values in the Web/App.Config. (more details can be given if needed).

Anyway, to do this we use reflection to accomplish our DataProvider class on which we can work.

/// <summary>
/// The constructor will create a new provider with the use of reflection.
/// If the assembly could not be loaded an AssemblyNotFoundException will be thrown.
/// </summary>
public DataAccessProviderFactory()
{
    string providerName = ConfigurationManager.AppSettings["DataProvider"];
    string providerFactoryName = ConfigurationManager.AppSettings["DataProviderFactory"];
    try
    {
     activeProvider = Assembly.Load(providerName);
     activeDataProviderFactory = (IDataProviderFactory)activeProvider.CreateInstance(providerFactoryName);
    }
    catch
    {
     throw new AssemblyNotFoundException();
    }
}

But now I'm wondering how slow reflection is?

+24  A: 

In most cases: more than fast enough. For example, if you are using this to create a DAL wrapper object, the time taken to create the object via reflection will be miniscule compared to the time it needs to connect to a network. So optimising this would be a waste of time.

If you are using reflection in a tight loop, there are tricks to improve it:

  • generics (using a wrapper where T : new() and MakeGenericType)
  • Delegate.CreateDelegate (to a typed delegate; doesn't work for constructors)
  • Reflection.Emit - hardcore
  • Expression (like Delegate.CreateDelegate, but more flexible, and works for constructors)

But for your purposes, CreateInstance is perfectly fine. Stick with that, and keep things simple.

Marc Gravell
+6  A: 

Here are some links that might help:

Ruben Steins
darn, this is quite shocking
Sem Dendoncker
Don't be shocked. The longest time measured was 22 seconds for a million iterations. 22 *micro*seconds per call for the worst case. Unless you're creating a huge number of these objects, it's really not a big deal. Of course, if you *are* creating a huge number of these objects, then it might be a big deal, but as Marc notes it's still going to be swamped by the database connection and query times. Don't be freaked out by "x times as slow" articles unless you know it's performance-critical.
itowlson
I agree, even though it is slower, for most applications, the performance penalty will not outweigh the benefits of using Reflection.
Ruben Steins
+1  A: 

Other than following the links given in other answers and ensuring you're not writing "pathalogically bad" code then for me the best answer to this is to test it yourself.

Only you know where you bottle necks are, how many times your reflection code will be user, whether the reflection code will be in tight loops etc. You know your business case, how many users will access your site, what the perf requirements are.

However, given the snippet of code you've shown here then my guess would be that the overhead of reflection isn't going to be a massive problem.

VS.NET web testing and performance testing features should make measuring the performance of this code pretty simple.

If you don't use reflection, what will your code look like? What limitations will it have? It may be that you can't live with the limitations that you find yourself with if you remove the reflection code. It might be worth trying to design this code without the reflection to see if it's possible or it the alternative is desirable.

Martin Peck
+2  A: 

Reflection is not THAT slow. Invoking a method by reflection is about 3 times slower than the normal way. That is no problem if you do this just once or in non-critical situations. If you use it 10'000 times in a time-critical method, I would consider to change the implementation.

Enyra
+4  A: 

Its slower compared to non-reflective code. The important thing is not if its slow, but if its slow where it counts. For instance, if you instantiate objects using reflection in web environment where expected concurency can rise up to 10K, it will be slow.

Anyway, its good not to be concerned about performance in advance. If things turns out to be slow, you can always speed them up if you designed things correctly so that parts that you expected might be in need of optimisation in future are localised.

You can check this famous article if you need speed up:

Dynamic... But Fast: The Tale of Three Monkeys, A Wolf and the DynamicMethod and ILGenerator Classes

majkinetor
A: 

I was doing somethign similar until I started playing with IoC. I would use a Spring object definition to specify the data provider - SQL, XML, or Mocks!

n8wrl
well that's our next step. we are allready using spring.net, but the clue is that we need to be able to change dataaccesslayer @runtime.
Sem Dendoncker
Spring.net is quite capable of updating dependencies at runtime. If you update the config file and reload an instance from the factory, you'll get a reference to the updated instance. (Note that this does not work if you load the config from app.config, only if you use a separate spring XML file.
Jacob