Improving dependency injection speed in the IoC Framework

I’ve been using the OpenNETCF IoC framework for several new projects lately, and I really like it.  I think my favorite feature is the fact it gives you the ability to subscribe to events from other objects without requiring an instance of the event publisher.  In fact you don’t even need to know the publishers type or even of its existence – you simply need to know the name of the event that might get raised.


The only downside I’ve hit lately is that the performance for creating objects is not fantastic.  Of course that’s to be expected.  To achieve all of this really loosely coupled architecture, we have to rely heavily on Reflection.  Not only do we have to do object creation through Reflection, but we have to do a lot of complex querying looking for type names and attributes, and this can take a while.


In an effort to improve things a bit, I’m working on updating the internal ObjectFactory class that is responsible for all of this heavy lifting.  I’ve added caches for most of the items that get queried through Reflection.  For example now when we want to find all of the published events from a specific Type, we use reflection the first time, but every subsequent time we pull the list from a cache.


A unit test for creating a single object that both publishes and subscribes to events yields nearly a 5,000% improvement in creating speed for the second object of the same type.  Yes, you read that right – it is 50 times faster creating the exact same object type the second time around.  There’s no avoiding the pain the first time we have to inspect a Type, but I’ve already noticed a marked improvement in app startup time using the new changes.

One thought on “Improving dependency injection speed in the IoC Framework”

  1. Hi Chris – I’ve been using the Funq (funq.codeplex.com/) DI container for the last few months in a Compact Framework application. I know there are many containers out there and everyone has a favourite (or is busy writing their own). I’ve personally found Funq to be really useful, fairly simple to understand, and light weight in terms of avoiding reflection overheads. I haven’t done any performance testing with it but having converted existing code to use it I can subjectively confirm I haven’t noticed any specific change in performance (but I can confirm the app has much better separation of concerns :-). If you have used it I would be interested in your opinion.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s