IoC Battle in 2015 results: Using Ninject – think again!

Most of my posts are directly Sitecore related, but this is a subject I would like to cover briefly. I have long been explaining to people that the only IoC container I have every had a REAL issue with when doing performance analysis on sites is ….. NINJECT.

During my time as a dev I have seen many a X vs Y vs Z posts, one such post was IoC Battle and then subsequently IoC Battle revisited. These posts were great, but are somewhat outdated… Things have moved on… So I thought I would take the time to post what this test is like in 2015. I updated the tests to VS2013, .net 4.5.1 and used the latest and greatest nuget packages for the appropriate container.

I also behaviour flattened Windsor since it’s (now) default behaviour for transient resolves is for container to release them, not the GC. And so… ON TO THE RESULTS!

The Results



All times are in ms.

  Singleton Reg. Singleton Resolve (1,000,000) Transient Reg. Transient Resolve (1,000,000)
new () 0.0736 36.715 0.1225 117.4632
Dynamo 36.27 45.5668 8.9744 129.6407
AutoFac Lambda 74.3074 435.4103 3.1436 5,925.4697
AutoFac 6.7398 505.0172 1.3278 23,424.3369
StructureMap 63.6955 1698.1238 2.4394 8,642.6167
Unity 3.5.1404.0 42.6585 701.2708 0.6438 15,290.684
Ninject 44.1536 4742.0586 2.131 245,996.6293
Castle Windsor 220.3506 353.9794 15.5518 42,269.1004
SimpleInjector 2.7.1 27.6195 82.3461 3.4763 182.1958


Well, as before – Ninject appears to be by far the least performant in these tests. Castle Windsor was a little down on the competition too. I personally still favour StructureMap over Autofac (unlike some of my colleagues), it’s a preference of the API’s.

Since the majority of the resolves you are likely to do in your app’s will be transient, I would definitely (usually) choose a decent transient performance over singleton.

The updated source is here on GitHub, I would love for you guys to take it and add your favourite IoC.

11 thoughts on “IoC Battle in 2015 results: Using Ninject – think again!

  1. Usual caveats about YMMV aside, its worth considering that for Sitecore you aren’t always getting the latest version of the libraries. The Solr package for Sitecore 7.5, for example, uses the 2.x version of Unity. Which is potentially much, much slower than the results shown here.

    So if these results are meaningful in your own dev environment (and I recommend further testing) then always factor in that you might have to do some assembly re-binding to get the latest updates.

    • Yes – your post is great 😀

      It’s interesting structuremap doesn’t seem to show the level of transient performance on yours as it does on this test ?

      I am debating doing a test for Agnostic IoC too – see if it slows the results down at all.

  2. Pingback: Migrating from Ninject to Simple Injector | Adrian Hesketh

  3. Pingback: Inversion of Control (IoC) Containers Basic Comparison between some IoC Containers | DOliva Dev

  4. Just read this blog post… would be interested in your thoughts, i.e.
    “To resolve large numbers of transient objects you should use the factory pattern, make the IoC Container resolve the factory as a singleton and inject any dependencies that the transient objects need into the factory. I don’t have many types of transient objects that need to be created, only a few classes, so I created factories for them and my performance problems melted like an arctic ice pack.”

    • I am unsure on why you would choose to explicitly create a factory to resolve individual components multiple times, it seems a little illogical. That said – it would indeed get around the speed issues found in ninject – and it is a practice I have used when forced to work with ninject as a container (which I have only had once).

      If (for example) you need to create your object for use in an MVC controller, you will have just added an additional resolve in order to get at your dependent object (even if the resolve is of a singleton). The speed of which is also dependent on your container. So I guess for me – it seems like an unnecessary step.

      If I was forced to create 1000’s of objects in a single cycle (ie: 1 page request lifecycle) I would probably make the controller / whatever responsible for the object creation using the ‘new’ keyword instead. Which again – doesn’t need a factory in place.

      Generally the only time I would opt to resolve a factory explicitly would be for types that share an interface – simpleinjector does not support named instances and expects this to be your solution for example.

  5. Pingback: Inversion de contrôle en .net | Sopra Steria Blog Technique

  6. Pingback: Selecting a .NET Inversion of Control Container - Accusoft

  7. Pingback: Dependency Injection with Unity - Local Code

  8. Pingback: WCF Services – Dependency Injection with StructureMap – Code Station

Leave a Reply

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

You are commenting using your 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 )

Connecting to %s