Ninject and performance

Question

I am reviewing code on a website that will have many concurrent users, approx. 100,000 authenticated users.

I found the following type code:

[Inject] public BusinessLayer.ILoginManager LoginManager { get; set; } 

And in global.asax.cs:

  protected Ninject.IKernel CreateKernel() { return new StandardKernel(new ServiceModule()); } internal class ServiceModule : NinjectModule { public override void Load() { Kernel.Bind<IReportProxy>().To<ReportProxy>().InRequestScope(); } } 

Q: Will using Ninject affect performance? Are there situations in which you should not use Ninject due to performance?

Answer 1

As always with questions and performance issues, you cannot find any of them just by looking at your code. Rather, profile your application and see where the problem is.

From my past experience, IoC containers carry an overhead of performance when running applications, and their impact is approaching little while the application is running.

Answer 2

Ninject caused us a lot of problems associated with working on a project. This is one of the slowest DIs, and I highly recommend considering a different DI engine (e.g. https://github.com/ninject/ninject/issues/84 )

A couple of other things to note about Ninject:

• Unbind / Rebind are not thread safe (AFAIK is not listed anywhere on xmldocs). Symptom: with interruptions, you may lose some bindings due to duplicate keys in Kenrel’s internal dictionary.

• A reference to a custom scope object of the binding object can lead to a memory leak (this is really reasonable, but Ninject does not help in any way in detecting the problem). For example. Bind an object that has a permalink to the HttpContext in the HttpContext.Current area

It is also worth keeping in mind that switching to another DI may not be possible depending on the set of functions that you ultimately use (for example, service location, conditional bindings, user areas, dynamic bindings, etc.). Even if another DI structure has a similar set of functions (for example, LightInject), the syntax may be too different.