Would a custom Dependency resolver slow down my MVC application?

Question

Wouldn't using a custom dependency resolver for an asp.net MVC 4 significantly slow down the app ? Considering it gets called for every single dependency instead of just the ones I need it to be called for ( below)

Is there a way to have the GetService(Type serviceType) called only when I have an interface which ninject can resolve, rather than asp.net calling GetService for every single dependency, like below., to make it faster? I'm using Ninject, which isn't the fastest to start with.

Or is this something I shouldn't be worrying about? Thanks

public class NinjectDependencyResolver : IDependencyResolver
..... unnecessary code not shown

public object GetService(Type serviceType)
{
    Debug.WriteLine("GetService was called for " + serviceType.ToString());
    return kernel.TryGet(serviceType);
}

The output window is showing

GetService was called for System.Web.Mvc.ITempDataProvider
GetService was called for System.Web.Mvc.Async.IAsyncActionInvoker
GetService was called for System.Web.Mvc.IActionInvoker
GetService was called for System.Web.Mvc.IViewPageActivator
GetService was called for ASP._Page_Views_Home_Index_cshtml ... GOES ON and ON....

Answer 1

You probably shouldn't worry about it.

If your ASP.NET MVC site is like a normal site, and has out-of-process call, like

• accessing a database
• calling web services
• accessing the file system
• etc.

then the majority (95+ %) of the page request time is going to be used there.

In general, DI Containers like NInject are fast; they are reusable libraries, and their creators have typically worked on making them as fast as possible. In fact, they don't do anything that MVC's internal DependencyResolver doesn't already do.

For more on this topic, read my (container-agnostic) article Compose object graphs with confidence, or view my talk Big Object Graphs Up Front.

You should also keep in mind Knuth's words, that premature optimization is the root of all evil. If you're worried about it: measure.

That's what I did, and what I report on, in my Big Object Graphs Up Front talk.