Is it worth replacing Ninject for performance reasons?

Question

I've got a reasonably-sized ASP.NET MVC/WebApi web application (~100KLOCS) that is creaking a bit under the load (about 1MM requests / day). For instance, a page typically takes 2-3 seconds to load, which is a good deal off from optimal. As I've started looking around for possible bottlenecks, I can't help but notice that Ninject, my IOC container, is rated the slowest by a very healthy margin:

http://www.palmmedia.de/Blog/2011/8/30/ioc-container-benchmark-performance-comparison https://github.com/ninject/ninject/issues/84

Has anybody else been in this position and tried replacing Ninject for something else, e.g., LightInject, SimpleInject, or something of that ilk? Was it worth the effort? Ninject seems to be the most popular, with lots of community and framework support, and I'm not at all eager to get myself hung out on a project that's going to end up being unsupported. Beyond that, I'm not sure how test to see whether, in a real world application, the IOC container's performance will even get noticed.

Anybody out there have any real-world stories or scars worth sharing? Or suggestions about how to tell if Ninject is even a bottleneck?

Subscapular

This question appears to be off-topic because it is not about a specific code-related problem. – Marylynnmarylynne

I'd disagree, but then I already believe that question topics should be broader than some of the more aggressive closers on SO seem to think :-). But this is related to a very specific coding problem: I'm using one framework in my code, have noticed some possible problems, and want to know whether those problems could be addressed with a different framework. Sounds fairly code-specific to me :-). – Subscapular

I agree with you on that point. Sorry for the close vote. Unvoted. – Marylynnmarylynne

Performance-optimisations should always only be done after identifying the problematic (slow) operations. So you'll have to start with profiling. When you find that some ninject operations are slow you can try to circumvent the bottlenecks (use other binding mechanism, adapt the design...) or see if another container can handle these operations faster. You might want to read The-Basics-of-ASP-NET-Performance-Optimization – Synonymous

Your DI container won't be a bottleneck unless you are using it as a Service Locator, which is yet another argument for avoiding the anti-pattern. If all DI happens in the Composition Root, the only performance effect you will see is on the initialization when the application pool recycles. IMHO performance is not a good reason for choosing a DI container because it will rarely impact the performance of a properly configured application. – Literal

@NightOwl888, registration may only happen at the composition root, but for an MVC app you will still be instantiating new objects on every request. In the benchmark referenced by the OP, Ninject is 1000x slower in the case where the IoC framework is automatically resolving nesting of dependencies. Add that to a web site or API that will be hit many times a second, I could see why he is worried about that cost becoming significant. I am curious as to what other folks have experienced on high volume websites, though I doubt it is consuming an extra 2 seconds unless there is some sort of bug. – Googins

Found another post on the topic this morning. Again Ninject is 1000x slower, with an individual transient resolve taking a quarter of a millisecond. While that doesn't sound like a lot, if you are doing that for multiple dependencies on a website that gets hundreds of requests per second, it does become a factor. IoC Battle in 2015 results: Using Ninject – think again! – Googins

@KenSmith , Its late but Can you share which DI you used for your wep application to overcome Ninject performance issue ? – Host

These days I'm using Microsoft's Unity framework, and using it entirely with reusable, singleton classes (rather than creating them afresh each time). It's not the fastest framework, but it's got reasonable support for my scenarios, and it's fast enough that I haven't noticed or suspected any issues. – Subscapular

Answer 1

I know I am a little late to the game with this question, and I'm sure you've already come to some conclusion, but this is something I find myself asking quite a lot lately. Ninject is certainly not the fastest, but it is (in my opinion), the most flexible and extensible framework I have ever used, and it is an absolute joy to work with. I have never run into an IoC problem that I couldn't resolve with Ninject.

It's a trade off really. When I am working with a client where flexibility and extensibility is key, usually internal facing line of business apps, I use Ninject. When I'm working on small focused components where performance is key, high volume external facing web services for example, I use something faster like SimpleInjector. However, I have time and again found it lacking when I need to do something more advanced, and end up replacing it eventually. As I adapt my methodologies to a micro-service style approach however, I have begun to see more value in smaller frameworks.

You would see a performance increase it sounds like with the type of volume you're seeing. But the perceived value of that performance increase is dependent entirely on how much value you place on flexibility and the other capabilities that Ninject Provides.

Meyeroff

Answer 2

"Worth it" can only be decided by you. Have you run a profiler on your site to see where the worst bottlenecks are? It might not even be Ninject that's your worst offender.

Certainly, anywhere you can shave some time off will be worth it for many people. But a lot of it depends on your usage. For instance, if you're generally injecting only a few objects with a shallow dependency graph, you probably won't see much benefit. But, if you have deep dependency graphs with hundreds of objects, then you might see a lot of benefit.

SimpleInjector is not likely to be abandoned soon, as the primary developer is a well known guy.

StructureMap is another good choice, although it's middle of the pack in performance, it's well supported and has a good community.

Defendant

Answer 3

Anybody wandering by this question again, might want to give DryIoC a try as well. Performance closer to SimpleInjector, but a bit more extensible. MS actually uses it for a few of their back end services, Azure Durable functions to name one.

Meyeroff