Daniel Palme has now integrated Rezolver into his benchmarks as standard, so now you can evaluate it's performance independently of our own tests shown here.
He regularly updates this blog post with in depth comments and analysis on his latest results.
The current status of Rezolver's performance is 'Average', which is fair, because of the results of the Child Container tests, which we are working on improving.
This page will continue to be maintained with our own copies of the results in order to flesh out the reasons behind any deficiencies in Rezolver, both in terms of features and performance, as well as keeping everyone updated on our progress in improving performance.
Benchmarking an IOC container obviously has pitfalls. In a web environment, for example, it's highly unlikely you'll hit the kind of traffic levels required for your choice of container to have a noticeable impact on speed.
But, that said, speed is still important - especially with something as fundamental as an object which is taking control of how you create your objects! In any case, if you're reading this then you're a developer - which means you're probably interested in how fast Rezolver stacks up against your previous favourite container ;)
Over on GitHub Daniel Palme has, for a while now, been maintaining a benchmarking suite for IOC containers - called IOCPerformance. In addition to our own performance analysis, this program offers an easy way to stress test the Rezolver containers both on their own, but also against other popular containers.
The tests include singletons, transients, objects which require a mixture of these, complex objects which require lots of nested dependencies, resolving enumerables and child containers, and does provide a reasonably thorough examination of a container's features in addition to its performance.
Excluding Rezolver and the 'No' container, which the baseline, there are 31 containers now being stress-tested by this application, with the list growing.
So, we forked this project and added an adapter for Rezolver. We then ran it on an Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz (power management options set to 'maximum performance' to ensure the processor runs at its maximum clock).
A couple of results which you'll find on the IOCPerformance page are left out of the individual results because Rezolver doesn't yet support them (specifically Interception and Conditional services) - implementations for these are planned.
Singleton service via SingletonTarget
Transient service using ConstructorTarget
Singleton and transient mixed together.
Deep dependency graph, mix of transient and singleton
Using GenericConstructorTarget to register
Foo<> and then request instances
Registering multiple services for
T and then resolving an
Create a new container from an existing one, register new services in it and resolve.
The poor performance of Rezolver here is caused by the fact that there's an overhead on the first Resolve call to a container, as that's when it compiles the associated ICompiledTarget for that service. Because of the way this benchmark is performed, it means that Rezolver spends most of its time dynamically compiling delegates.
A solution is in the pipeline for this, which will be implemented once we've implemented another compiler that's based entirely on reflection and late-bound delegates instead of dynamically constructed expression trees. When this is done and merged with the current expression-tree based compiler, the performance of child containers will improve drastically.
Registering/Preparing the Container
Creating a container, registering services and optionally 'baking' the container (not required by Rezolver).
Registering/Preparing the Container (+ Resolve)
Same as above, except a resolve operation is then subsequently fired at the container. Again, Rezolver suffers for the same reason as with the child containers. When performance for that has been improved, then this one will also.
'Advanced' compound results
All the so-called 'advanced' operations' times summed and graphed (note - if a container doesn't even support a particular feature, then there's a good chance it'll be higher up these graphs).
Rezolver doesn't make it into the 'Fast' graph purely because of the aforementioned first-call overhead when resolving a service of a given type for the very first time. This will change.
'Basic' compound results
All the so-called 'basic' operations' times summed and graphed (again - if a container doesn't even support a particular feature, then it'll be higher up these graphs).
Top 10 for Rezolver!
Register/Prepare (+ Resolve operation)