Skip to main content

ASP.NET MVC: Performance tips

Although there are a lot of different ways to optimize your ASP.NET MVC web applications, some are cheaper then others. Here are some very simple tips that still can make a significant difference:
Run in Release mode
Always make sure that your application is compiled in Release mode and that your web.config file is configured with <compilation debug="false" />. Use the web.config transformations feature to automatically change this value in release mode.
Use only the View Engines that you need
As you probably know the MVC framework supports multiple view engines. This means that each time MVC is trying to find a view it’s searching through all these view engines. In MVC 3 two view engines are registered by default (WebForms and Razor). So if you use only one view engine, remove the ones you are not using:
protected void Application_Start() 
{ 
	ViewEngines.Engines.Clear(); 
	ViewEngines.Engines.Add(new RazorViewEngine()); 
}
Use the CachedDataAnnotationsModelMetadataProvider from ASP.NET MVC Futures
In the ASP.NET MVC 3 Futures you can find a little gem called the CachedDataAnnotationsModelMetadataProvider. For using this provider, just open global.asax file and add the following line in the Application_Start method, 


ModelMetadataProviders.Current = new CachedDataAnnotationsModelMetadataProvider();


Avoid passing null models to views
Don’t pass in a null model to a view that uses strongly-typed html helpers (such as Html.TextBoxFor). Strongly-typed html helpers such as Html.TextBoxFor(m => m.Name) will try to emit the value of the model using the provided expression. However when something along the expression chain is null a NullReferenceException will be thrown when the expression gets evaluated. MVC’s expression evaluator catches the exception but on a page with multiple such html helpers the cost of the exception adds up. You can avoid that cost by always passing an empty instance of the model to the view:


public ActionResult Insert() 
{ 
	return View(new Product()); 
}

Uninstall URL Rewrite if you don’t use it
When performing URL generation (for example via a method like Html.ActionLink) in some cases MVC checks to see if the currently requested URL has been rewritten by the URL Rewrite module. If that is the case the result is processed so that it correctly matches the URL requested by the client. The act of checking if a URL has been rewritten has a non-trivial cost (because it involves checking server variables). ASP.NET MVC 3 checks to see if URL Rewrite is turned off and can cache that fact thus avoiding the need to inspect server variables for each request. If URL Rewrite is turned on MVC will have to check server variables even if no rewriting happened for a particular request so if you are not using URL Rewrite you should turn it off.

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

VS Code Planning mode

After the introduction of Plan mode in Visual Studio , it now also found its way into VS Code. Planning mode, or as I like to call it 'Hannibal mode', extends GitHub Copilot's Agent Mode capabilities to handle larger, multi-step coding tasks with a structured approach. Instead of jumping straight into code generation, Planning mode creates a detailed execution plan. If you want more details, have a look at my previous post . Putting plan mode into action VS Code takes a different approach compared to Visual Studio when using plan mode. Instead of a configuration setting that you can activate but have limited control over, planning is available as a separate chat mode/agent: I like this approach better than how Visual Studio does it as you have explicit control when plan mode is activated. Instead of immediately diving into execution, the plan agent creates a plan and asks some follow up questions: You can further edit the plan by clicking on ‘Open in Editor’: ...