IoC Container Benchmark - Unity, Windsor, StructureMap and Spring.NET

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:

• Castle Windsor
  • Part of the popular Castle Project.
  • First introduced in 2004
• StructureMap
  • Sourceforge project maintained and created by Jeremy D. Miller
• Spring.NET
  • Inspired by the spring java framework
  • First introduced in 2004, www.springframework.net
• Unity
  • Created by the Microsoft Patterns Practices team
  • First released in April 2008
  • Project homepage on codeplex

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:

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

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.

http://lh3.ggpht.com/torkel.odegaard/SALo6OJA3yI/AAAAAAAAAWg/Nhrvuby1VUE/s1600-h/IoCInversed[5].png

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

Posted by Torkel Ödegaard at 6:46 AM

Labels: Benchmarks, C#, Castle, IoC

13 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

April 14, 2008 1:20 PM 

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.

April 14, 2008 1:25 PM 

Joshua said...

I would interested to see how Ninject compares.

April 14, 2008 6:57 PM 

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!

April 14, 2008 7:40 PM 

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.

April 16, 2008 3:53 PM 

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 :)

April 16, 2008 4:25 PM 

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!

April 16, 2008 9:43 PM 

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 ;-) )

April 16, 2008 10:09 PM 

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.

April 16, 2008 10:41 PM 

Anonymous said...

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

April 17, 2008 9:20 AM 

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 ;)

April 20, 2008 8:09 AM 

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.

June 16, 2008 6:24 AM 

Luke said...

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

July 6, 2008 5:31 PM

本文转自海天一鸥博客园博客，原文链接：http://www.cnblogs.com/sgsoft/archive/2011/07/28/2119967.html，如需转载请自行联系原作者