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.
- 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.