Nate Kohari informed me that he fixed the performance issue that I discovered in my last test, so I thought I rerun the benchmark against the trunk version (revision 62) of Ninject.

I have also included another new container named Autofac, written by Nicholas Blumhardt and Rinat Abdullin.

This container has nice list of features, here are a few:

• Autowiring (with out any intrusive attributes)
• XML Configuration Support
• Nice C# registration API (including possibility to create components with expressions)
• Module system (nice way to structure parts of your application)
• Nested containers

The registration API is at first glance like any other IoC container except it also provides the ability to override the autowiring by defining how components are created by using lambda expressions. Here is an example:

// using autowiring
builder.Register<UserController>().FactoryScoped();
// using expressions
builder.Register(c => new UserController(c.Resolve<IUserRepository>(), c.Resolve<IAuthentificationService>()))
  .FactoryScoped();

The second method could potentially be a lot faster since in it you create a anonymous method that creates the object directly. There is a lot more code to write and if you change the constructor you need to update the registration code, so I am not sure you would want to use it to for most components. To be fair to the other containers in the test I tested Autofac with both autowiring registration and with expression based registration. For more detail on how the benchmark works please view the first benchmark post.

Another interesting feature of Autofac is it's support for nested containers with predicable component cleanup. 

var container = // ...
using (var context = container.CreateInnerContainer())
{
  var controller = context.Resolve<IController>();
  controller.Execute(); // use controller..
}

In the above example the controller and all it's dependencies that implements IDisposable will be disposed.

Here are the results:

It is nice to see that the Ninject problem has been solved. When using Autofacs expression (lambda) based registration API the results are, not surprising, a lot quicker than the other containers. I would have almost through that the performance difference was going be bigger, seeing how fast the new operator was in my first benchmark (where I made a crude comparison with using the new operator directly to create all the instances).  

My conclusion is the same as after the first test, the performance difference is not significant to warrant consideration when choosing a IoC container. Unless you create a incredibly large amount of transient components (not recommended), then maybe use Autofac :)

It was fun to try out Autofac, it is looking like an interesting contender, and might even replace Castle Windsor as my favorite. I doubt it though, Castle Windsor probably has the largest user base and I am pretty familiar with it's codebase / extension points. But who knows, you shouldn't always stick to what you know :)

For the benchmark code: IoCBenchmark_ReRevisted.zip

Microsoft seems to be about reinventing the wheel again, Krzysztof blogged about a new framework being worked on with these goals:

MEF is a set of features referred in the academic community and in the industry as a Naming and Activation Service (returns an object given a “name”), Dependency Injection (DI) framework, and a Structural Type System (duck typing)

They are currently just experimenting with different approaches and a CTP is likely to be released soon. The example that Krzysztof showed might not be indicative of how it will eventually turn out but it doesn't look very promising (requiring property attributes to declare dependencies, etc).

The approach I was hoping that Microsoft would take was to try and incorporate the concepts of an IoC container but make the concrete container pluggable. Maybe even to introduce this concept on the CLR level or maybe just C#/VB. Maybe something like this:

this.authService = resolve IAuthentificationService

If C# could introduce a new keyword (resolve) that would request a component from a container. The .NET framework would probably need a basic implementation of the container but it should be completely pluggable so you can exchange it with for example Castle Windsor or StructureMap. I haven't really thought this through but If Microsoft is going to include an IoC Container in the core framework this is the approach I wish they would at least try (maybe they have?).

Someone (Joshua) mentioned Ninject in the comments to in my IoC Benchmark. I hadn't heard of this project before but after checking out ninject.org and seeing the project slogan "lighning-fast dependency injection" I felt that it deserved be included in the test.

I am not sure what the slogan refers to though, lightning-fast usage and setup or runtime performance? Anyway it has a nice fluent registration API:

Bind<IUserRepository>()
  .To<LdapUserRepository>()
  .Using<SingletonBehavior>();
  
Bind<IAuthentificationService>()
  .To<DefaultAuthentificationService>()
  .Using<SingletonBehavior>();

Bind<UserController>()
  .ToSelf()
  .Using<SingletonBehavior>(); 

The tests were made with the release build of RC1 downloaded from the project homepage. I was kind of surprised by the results:

I might be doing something wrong here but this is the result I got. For the transient case there seems to be a big memory leak. The Ninject kernel seems to keep references to transient objects. I tried the kernel's Release function but the memory leak was still evident.

Just to check that it was not something wrong with my code I did a profiling trace with JetBrains dotTrace:

It could still be me setting something up in the wrong way, but it looks like it's a bug in the Ninject Core.

Just a note: I think that doing premature optimization can result in bad design and architecture. The reason I did this and the previous test was not to find the fastest container, it was firstly to get a change to play with new (to me) containers, and secondly to see if there were any significant performance difference between them worthy of taking into account when choosing a container.

My conclusion in the previous test was that the difference in performance was not big enough to be relevant compared to other aspects of the containers, like how much you like the API or the features. The Ninject result for the transient test above is very significant, however it is probably caused by a memory bug in the release candidate and will likely be fixed in the next release. If you disregard this bug I actually kind of liked Ninject, it a had a nice API and a way of doing things, but it's slogan is currently a little misleading :)

For the complete code: IoCBenchmark_Revisited.zip

Updated (2008-05-05):

Nate Kohari has fixed the performance issue, the results are now inline with the other containers. For the new results (which also includes Autofac) please view this post.

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.

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

For a previous project I extended the IoC container Castle Windsor to support dynamic component selection. In this case it was extended to select the correct implementation based on the current user type. I even wrote a CodeProject article about it, but for some reason I never published the article. Well this morning I did submit it and it can be found here. I will try to outline the changes I did in this post as well.

Why do you need dynamic component selection? Well imagine you are going to develop a web application that is used by B2C (Consumer), B2P (Partner) and B2E (Employee) users. The B2C users has their profile and password in a local database, the B2P users profile can only be accessed via an external third party web service and the B2E users are in an LDAP server.

In this kind of scenario you would do an interface for a user repository and then an implementation for each user type. If this web application serves all these user types from a single instance then you need a factory to return the correct implementation based on the current user type. If you have many different scenarios where the implementation will be different based on some common runtime condition then it would be nice to declare that (for example in a xml configuration file) and then have the inversion of control container dynamically select the correct component. This way you would not need to create a bunch of almost identical factories for each scenario.

So what we want to do is basically state in the windsor configuration which implementation coresponds to which user type.

<components>
    <component	id="b2e.user.repository"
		service="ExtendingWindsor.IUserRepository, ExtendingWindsor"
		type="ExtendingWindsor.EmployeeUserRepository, ExtendingWindsor" 
		channel="B2E" />
    
    <component	id="b2c.user.repository"
		service="ExtendingWindsor.IUserRepository, ExtendingWindsor"
		type="ExtendingWindsor.ConsumerUserRepository, ExtendingWindsor" 
		channel="B2C" />

    <component	id="b2p.user.repository"
		service="ExtendingWindsor.IUserRepository, ExtendingWindsor"
		type="ExtendingWindsor.PartnerUserRepository, ExtendingWindsor" 
		channel="B2P" />
</components>

The channel attribute in the above xml is not something that exists in the standard Castle Windsor configuration schema. However Castle Windsor allows for additional attributes so the only thing we need to do now is to extend the container so that when it searches for a implementation of the IUserRepository interface it will take the correct one.

One way to acheive this is to exchange the default naming subsystem with one that inherits from DefaultNamingSubSystem and change the behavior of the GetHandler method.

public class ExtendedNamingSubSystem : DefaultNamingSubSystem
{
    public override IHandler GetHandler(Type service)
    {
        IHandler[] handlers = base.GetHandlers(service);

        if (handlers.Length < 2)
            return base.GetHandler(service);

        UserPrincipal user = (UserPrincipal) Thread.CurrentPrincipal;

        foreach (IHandler handler in handlers)
        {
            string channel = handler.ComponentModel.Configuration.Attributes["channel"];
            if (channel == user.Channel)
            {
                return handler;
            }
        }

        // use default
        return base.GetHandler(service);
    }
}

What we need to do now is to replace the default NamingSubSystem with our own. To exchange the NamingSubSystem of the underlying kernel in Castle Windsor is a little more problematic than it should. We need to use the constructur that takes in an implementation of IKernel.

This is what we have to do:

IKernel kernel = new DefaultKernel();
kernel.AddSubSystem(SubSystemConstants.NamingKey, new ExtendedNamingSubSystem());
XmlInterpreter interpreter = new XmlInterpreter();
DefaultComponentInstaller installer = new DefaultComponentInstaller();

interpreter.Kernel = kernel;
interpreter.ProcessResource(interpreter.Source, kernel.ConfigurationStore);

WindsorContainer container = new WindsorContainer(kernel, installer);
container.Installer.SetUp(container, kernel.ConfigurationStore);

This is setup is a little more complex than what you normaly do:

WindsorContainer container = new WindsorContainer(new XmlInterpreter())

But there is no constructor that takes an IKernel and a IConfigurationInterpreter. I have thought about submitting such a constructor as a patch to the castle team but have not gotten around to it. Anyway now that we are done we can do this:

IUserRepository repos = container.Resolve<IUserRepository>();

The container will dynamically select the correct component based on the current principal. This also works if you have a component that has a constructor dependency to the IUserRepository. You have think about the lifestyle though so that you do not store a reference to a IUserRepository implementation in a singleton component.

Please observe that the above implementation of ExtendedNamingSubSystem is just a proof of concept implementation. For a real implementation you should try to reduce the need to call base.GetHandlers(service).

Update: Instead of extending the DefaultNamingSubSystem yourself you can use the KeySearchNamingSubsystem which is included in the Castle Windsor release. This allows you to use meta data inserted in the component id to do dynamic component selection. 

I really like the new component registration API in Castle Windsor, if you compile the trunk yourself with Visual Studio 2008 you also get some .NET 3.5 only methods that uses lambda functions. These new functions make the API really powerfull.

// Register services
Container.Register(AllTypes.Pick()
    .FromAssembly(Assembly.GetExecutingAssembly())
    .If(type => type.Namespace == typeof(ISearchService).Namespace)
    .WithService.FirstInterface());

This registers all classes that exists in the same namespace as the ISearchService interface. When windsor registers the classes it will take the first interface as the main interface (the one you can use to get the component). The nice this is that this can be used together with the xml based configuration since only components that are not already registered will be added. This gives you a change to later change a component via the xml configuration.

Ayende has been posting a lot about automatic component registration using Binsor windsor configuration scripts. The programming experience when all components are registered and hooked up automatically is really nice. It lets you focus on the important stuff.