There are a number of inversion of control containers out there so I thought it would be an interesting experiment to do a simple benchmark. There are different ways that one can instantiate a type in .NET, for example via the new operator, Activator, GetUninitializedObject and Dynamic Method. The performance difference between these methods are in some cases quite high, maybe the same is true for these IoC containers? Granted IoC containers do more than just create objects so other factors will probably play a big role in the results.

So here are the contestants:

I have been using Castle Windsor since 2005 and I think it is the best of the bunch, so I guess I am unconsciously biased toward Windsor.  However I will try to make this benchmark as objective as I can.

The scenario for this test:

  • Have each IoC container resolve a UserController 1000 000 times
  • The UserController will have two constructor dependencies
  • Run the test with transient (new instance for each resolve) and singleton components

The UserController looks like this:

public class UserController
{
    private IUserRepository repository;
    private IAuthentificationService authService;

    public UserController(IUserRepository repository, IAuthentificationService authService)
    {
        this.repository = repository;
        this.authService = authService;
    }
}

I have also a general container interface that the benchmark engine will use. Each container will implement this interface.

public interface IContainer
{
    string Name { get; }

    T Resolve<T>();
    
    void SetupForTransientTest();
    void SetupForSingletonTest();
}

All tests used the latest released version of each library. Before you interpret these charts please observe that the measurement is for one million component resolves which means the actual time difference between each container is actually very small.

Here are the results when all components were setup as singletons:

IoCSingleton

Here are the results when all components were setup as transient:

IoCTransient

So what does these charts tell us? Lets take the biggest difference in the transient case, Spring.NET took 44.149 seconds and Unity took 8.164 seconds, what is the actual difference when resolving a single instance?

  Spring.NET : 44.149 / 1000000 = 0.000044149 seconds
  Unity      :  8.164 / 1000000 = 0.000008164 seconds

So the actual difference is only about 36 microseconds. Another way to put these values into perspective is to compare against the new operator. I created a NewOperatorContainer with a resolve method that looks like this:

public T Resolve<T>()
{
    object o = new UserController(new LdapUserRepository(), new DefaultAuthentificationService());
    return (T) o;
}

OK, comparing the above with an inversion of control container is like comparing apples to oranges, an IoC handles so much more than just object creation. Also an IoC cannot use the new operator directly but must use one of the other methods. My guess is that all IoC containers in this test uses an approach which involve IL Generation which if cashed comes close to using the new operator directly. Anyway I think it will show just how small the difference between the real IoC containers are. In order to visualize this I needed to invert the values so that high means fast and low means slow.

IoCInversed

Update: The above chart can be very misleading. The x-axis is not seconds but 1/s. I hope it shows that the difference between the containers are very small compared to instantiating the objects manually.

OK, can we draw any conclusion from the test? Well I think we can say that performance should not be an issue when choosing one of these IoC containers. The difference is too small. When you choose which container to use you should consider other aspects, like how invasive the container is to they way you want to work.

For the complete code: IoCBenchmark.zip

17 comments:

Anonymous said...

IMHO your last graph is very misleading. why do you use the inverse values? use the usual values and point out how tiny the "new" value is - or if you feel like the inverse is beneficial at least label your axis correctly.

otherwise nice article

Torkel Ödegaard said...

Yes, you are right. I also feel that the last graph is too misleading. I will correct it when I get home from work.

Joshua said...

I would interested to see how Ninject compares.

Torkel Ödegaard said...

I guess it should have been in the test having a slogan like "Lightning-fast dependency injection for .NET"

Hopefully I will have time to do it later in the week, thanks for the tip!

Bil Simser said...

This is interesting but IMHO a bit of a waste of time. I mean, what application would *ever* need to try to create a million objects all at once? Even in a tight loop you *might* create a few thousand objects. I just can't think of any use case where this situation would ever manifest itself so to me the numbers are pretty meaningless. Interesting to look at, but not of any value to judge something by. If the differences were significant with say a few hundred objects then maybe this exercise would be worth something.

Torkel Ödegaard said...

Yes, I agree that this is not a realistic scenario. Doing one million resolves is not something that do in one request. That was just to accumulate the performance difference to see if there were any substantial difference.

I don't think it was a waste of time, because it could have potentially been a big meaningful difference between them. Now it turned out that there weren't but that didn't make the test meaningless, because now you know :)

Nate Kohari said...

Nice post. I'd also be interested to know how Ninject does in comparison. :)

Bil's right, though, that it wouldn't typically make a difference, because most applications don't need to create 1,000,000 instances. However, faster IoC also means that you can use it in places that you wouldn't otherwise be able to -- for example, devices that support the compact framework.

Still a worthwhile study, and it's interesting to see the results!

Ruurd Boeke said...

I'm sorry, but if you are going to do a test and find a huge relative difference, you should not disregard it by looking at the absolute difference. What's the point in doing the test than?

I think it's pretty clear that no container takes a very long time, so what were you hoping to find?

(no disrespect meant, I clicked on the post because I was curious as well ;-) )

Torkel Ödegaard said...

Well the point was to check if there was any relevant difference, not to check which was the fastest.

And I think you can actually disregard a relative difference if that difference is still not relevant when you look at the absolute performance.

My conclusion to the test was that the relative difference was too small to make any relevant difference in real applications.

Anonymous said...

Nice benchmark. A functional comparison for the used Ioc Containers would be interesting. Where do the performance differences come from?

Nick said...

I think the comment about functional differences is important - what are you getting for you time?

In a real app with more components, the factors affecting container performance will shift from the expense of creating instances, to the expense associated with algorithms that are affected by the number of instances (e.g. which instance from many should be returned?) and algorithms that take a time proportional to the size of the dependency graph (e.g. circular dependency checking.)

You can never tell where that performance bottleneck is going to be until you measure it ;)

sharkboy said...

I think what this page shows is that using IOC containers will not make your app significantly slower. What makes apps slow are poor design, bad databases, and network latency.

As to which one to use, you have to try and figure out which one has a future.
I would rule out Spring.Net because it is a Java port and will always be several steps behind in supporting the latest .Net framework features.
StructureMap is cool but since only one guy is supporting it I would expect the project to die once that dude gets tired of dealing with it.

Unity may be the safe bet being that it has "Official" support from Microsoft. The MS guys where starting to promote this at TechEd this year. On the other hand, don't expect any innovation from Microsoft.

If you want a supported component, go with Unity. If you want innovation, go Windsor.

Luke said...

You clearly don't know Jeremy Miller very well if you think that's what'll happen with StructureMap.

Anonymous said...

Thanks for the post. I am currently evaluating IOC containers and this was helpful if only to see the differences between the configuration of the containers.

Anonymous said...

The post is quite informative. I was wondering about IoC framework performance. Now my curiosity is satisfied. I need to choose the best one, though I'm choosing between Unity and Spring.Net. So far haven't found any significant pros/cons.
Thanks for the great and clear article.

per Nalin said...

Interesting analysis. Here's an updated performance comparison that includes a few more containers. http://www.iocbattle.com/

Anonymous said...

Interesting and useful. So, after a while trying to use Unity or other IoC containers, I find Unity is a appropriate choice for transient lifetime which is the most one used.