Below are some comments from Daniel de Palme’s IOC Container performance benchmark and my responses.
http://www.palmmedia.de/blog/2011/8/30/ioc-container-benchmark-performance-comparison Post #48
Something to notice about fFastInjector is that it is static, and it is made pretty much only for speed by creating a static generic class for every registration instead of storing them in some sort of collection like all the other (it does use a collection - but only to map resolving by Type to the static generic class).
fFastInjector is static but that is not only for speed. It also creates a very small and concise code base.
The thing to remember about dependency injection is that it is all about answering the question of “please give me an instance of (some type).”
In the case of an interface, the injector needs to determine where and how to get or create an instance.
The thing is that if you use something like MVC everything is resolved using the Type and not using a generic parameter, and then the performance decreases.
Only the first resolution is resolved using Type. If you resolve a controller that has multiple dependencies in the constructor, those dependencies are resolved generically, not through a passed type parameter.
So it performs very nice under the test conditions but in a real world scenario it is no different from the other fast containers, and doesn’t have the same feature set and seems difficult (if not currently impossible) to extend with custom lifetime registrations (for example perRequest or perSession lifetimes for Web scenarios or perThread etc.).
fFastInjector is smaller than other containers and it is very compatible with different project types. In fact, I am very proud that with fFastInjector-embedded, you can add a small injector to your code by just adding a source file.
I would recommend that the tests are change to resolve using the most basic way (using the Type and not Generics) to prevent this scenario.
Resolving using the generic parameter is only relevant if you are manually wiring everything up yourself, if you are using auto-wiring which I hope pretty much everybody prefer, then the Type is used.
I think it would be reasonable for the performance benchmark to have 2 adapters for containers that support generic resolution. One could call the generic resolver and the other could call the method with the type parameter.
Note that fFastInjector does automatically wire up concrete classes such that a call to Resolve<ConcreteClass>() will attempt to satisfy any parameters the constructor requires (by default, using the constructor with the fewest number of parameters).