Short answer

Not.

Long answer

The number of controllers does not have as much of a performance impact as how expensive each controller instance is to create.

The amount of overhead you can get for the number of controllers is negligible. Although MVC uses .NET Reflection to identify the current controller type, it is optimized for namespace lookups <Project Name>.Controllers

in the first place. But this list is cached in the file, so after the first hit, the performance is pretty good.

If you run into performance issues, this is when you do heavy processing in the controller constructor. The framework instantiates the controller for every request, so you should make it as cheap as possible to instantiate the controller. If you follow DI-centric (dependent introduction), even if you don't actually use DI in your project, you will be able to keep the cost of creating a controller instance to a minimum.

What this means in plain English - inline your dependencies into the constructor when the controller is just created. Don't actually do the processing in the constructor, defer to calling the actual action method.

public interface IHeavyProcessingService
{
    IProcessingResult DoSomethingExpensive();
}

public class HeavyProcessingService : IHeavyProcessingService
{
    public HeavyProcessingService() { 
    }

    public IProcessingResult DoSomethingExpensive() {
        // Lots of heavy processing
        System.Threading.Thread.Sleep(300);
    }
}

public class HomeController
{
    private readonly IHeavyProcessingService heavyProcessingService;

    // The constructor does no heavy processing. It is deferred until after
    // the instance is created by HeavyProcessingService. 
    // The only thing happening here is assignment of dependencies.
    public HomeController(IHeavyProcessingService heavyProcessingService) {

        if (heavyProcessingService == null)
            throw new ArgumentNullException("heavyProcessingService");

        this.heavyProcessingService = heavyProcessingService;
    };

    public ActionResult Index()
    {
        var result = this.heavyProcessingService.DoSomethingExpensive();

        // Do something with the result of the heavy processing

        return View();
    }

    public ActionResult About()
    {
        return View();
    }

    public ActionResult Contact()
    {
        return View();
    }
}

      

        
        
        
      

    

See this answer for details .

If you actually use a DI container in your application, you can improve performance even more by choosing the right lifestyle for each dependency. If you can share the same dependency instance across multiple controller instances (single user lifestyle), it makes the controller instance even cheaper to create.

"What are spins" is not necessarily true. The number of dependencies doesn't really matter, as they must create expensive dependencies. As long as the constructors remain light and simple, and the correct lifestyle is used for each dependency, performance won't be an issue no matter how many dependencies the controller has. However, the controller should have no more than 5 direct dependencies, after which you should refactor the service aggregation , making the dependency hierarchy look more like an inverted pyramid rather than a flat set that is all injected into the controller.