Blog > IoC Container Benchmark - Performance comparison

IoC Container Benchmark - Performance comparison

by Daniel Palme 11 Comments

Enterprise Library In this post I will do a performance comparison of the most popular IoC containers.
Of course performance is not the only criteria when choosing a container for a project. Perhaps you need features like interception, then not all containers are suited. But if the container is "only" used for wiring up dependencies, why not choose the fastest one?

The test setup

The contestants

You probably have heard of most of the frameworks, but one of them is quite new and works differently: Hiro
The author, Philip Laureano, names it an "inversion of control container compiler framework". After configuration, the container gets compiled and is immutable from now on. This concept makes this container really fast.

The test setup

To test the performance I register three interfaces and their corresponding implementation to every container.
The first one is registered as a singleton, the second one as transient (a new instance is created every time). The third also has a transient lifetime, but moreover has a dependency to the first two interfaces (which get injected by constructor injection).

Every interface is resolved 1.000.000 times and the time is measured in milliseconds.

The results

Overview

ContainerSingletonTransientCombined
AutoFac94338358904
Dynamo8481143
Funq98114299
LightCore20211434566
Hiro9085101
LinFu60922808865961
Munq132146412
Ninject68991592041245
Petite8791282
SimpleInjector8098121
Spring.NET423125741478650
StructureMap130413574489
TinyIoc467613821035
Unity179923557804
Windsor63832289189

Singleton

IocPerformance - Singleton

Transient

IocPerformance - Transient

Combined

IocPerformance - Combined

Conclusion

Spring.NET is definitely the slowest container. Another disadvantage is, that Spring.NET can only be configured with XML.

LinFu and Ninject are both much faster than Spring.NET, but still pretty slow.
AutoFac and Windsor come next, followed by StructureMap, Unity and LightCore.

SimpleInjector, Hiro, Funq and Munq offer the best performance, they are extremely fast. Give them a try!
Especially Simple Injector seems to be a good choice. It's very fast, has a good documentation and also supports advanced scenarios like interception.

Updates

13.09.2011: Funq and Munq have been added to the list of contestants, both frameworks are really fast. The updated charts do no more contain Spring.NET, since it was extremly slow.

04.11.2011: I added Simple Injector, the performance is the best of all contestants.

16.12.2011: I added Dynamo.Ioc, the performance is very close to Simple Injector and Hiro.

22.01.2012: Added TinyIoc.

22.02.2012: Updated IServiceLocator implementations.

Downloads

IocPerformance.7z

 

New comment

:

:

:

:

 

Comments

#1
Andrew Would you like to include some other less prominent IoCs in the comparison?

Funq http://funq.codeplex.com/
Munq http://munq.codeplex.com/
S2Container.NET http://s2container.net.seasar.org/en/index.html
PicoContainer http://docs.codehaus.org/display/PICO/Home

09/12/2011 by Andrew

#2
Daniel @Andrew:
Thanks for your hint. I have added Funq and Munq to the comparison. PicoContainer is a Java container and Seasar is not very easy to use, so I did not add these frameworks.
Funq and Munq are really fast.

09/13/2011 by Daniel

#3
Ady Could you state the version of each IOC that you have compared ?

11/03/2011 by Ady

#4
Daniel @Ady:
I added the version information

11/03/2011 by Daniel

#5
Pranav Shah Would you consider adding two more to the list:
http://www.dynamoioc.com/
http://www.dynamoioc.com/

I came across them while reading another article:
http://blog.opennetcf.com/ctacke/2011/04/29/BenchmarkingOpenNETCFsIoCFramework.aspx

12/16/2011 by Pranav Shah

#6
tibel Please check also:
https://github.com/grumpydev/TinyIoC
http://microioc.codeplex.com/

Another interesting point would be, if the IoC container will also work on silverlight, compact framework or WP7...

01/21/2012 by tibel

#7
Marijn Interesting read. Any thought on why you think Spring.NET is so slow? Maybe you could update your post to clarify that your test is only testing ServiceLocator style usage of the container.

02/01/2012 by Marijn

#8
Daniel @Marijn:
I don't know why Spring is that slow.
I'm only testing service location, since all other features like interception are not supported by all containers.

02/01/2012 by Daniel

#9
Will Not sure why xml configuration is a detriment. I hear developers complain about that and I just scratch my head. Oh, well, Spring.NET with all of it's useful facilities works for me.

02/09/2012 by Will | http://www.storm-studios.net

#10
Tomas Jansson Interesting comparison, but...

I've downloaded your code and I don't think you give the framework funq a fair comparison. The strength in funq is that it is using generics and therefor doesn't need to use any reflection and everything is already typed. If you look at munq, which I think is a fork of funq, it has really impressive numbers and funq should have approximately the same. Also, I changed your implementation and inherited directly from IServiceLocator instead of ServiceLocatorImpl and got numbers that are far from you result.

So please, when you do a benchmark do it the way that shows of the strength of all the frameworks.

02/22/2012 by Tomas Jansson | http://blog.tomasjansson.com

#11
Daniel @Tomas:
Thanks for your feedback. I changed the code accordingly. Now I inherit directly from IServiceLocator. Funq and Petite perform much better now.

02/22/2012 by Daniel