In debug mode, view resolution is optimized for ease of development. MVC iterates through the view resolution process each and every time your code renders a named view. That’s helpful since you obviously do want the environment to respond immediately to your changes when you’re working on a site.
In release mode, however, MVC’s view resolution is optimized for performance. When a view location is successfully resolved in release mode, MVC caches the result of that lookup and doesn’t need to perform another filesystem search when it encounters a reference to that named view again.
The result is that the apparent inefficiency of having WebForms’ naming conventions take precedence over Razor’s becomes negligible after the first resolution. So long as you don’t allow your production sites to run in debug mode, the view resolution issue is almost entirely eliminated.
debug=”false” – not just for view engines
View resolution caching is just one reason of many to ensure that you do not run your production sites in debug mode. Other serious drawbacks include:
- Timeouts – Have you ever noticed that you can spend an indefinite amount of time fooling around in the debugger without a halted request timing out? That’s because debug=”true” disables timeouts entirely, which is never a good idea on a live site.
- Bundling and Minification – ASP.NET’s new web optimization feature can automatically bundle and minify your JavaScript and CSS, but it only does so in release mode. When you run with debug=”true”, bundles are served as separate, unminified, uncombined script references with short caching headers. That’s important during development so you can read/debug your JavaScript code, but it defeats the entire point of the optimization exercise in production.
- WebResource.axd caching – Speaking of client-side resource optimization, resources served through WebResource.axd include aggressive caching headers in release mode. In debug mode, they are not cached at all.
