Scott Guthrie (manager of the ASP.NET development team) has an interesting post about it.
The most important points why you should not leave debug="true" are:
- The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)
- Code can execute slower (since some additional debug paths are enabled)
- Much more memory is used within the application at runtime
- Scripts and images downloaded from the WebResources.axd handler are not cached by the browser, resulting in more requests between
client and server
He also mentions the flag <deployment retail=”true”/> in machine.config, which allows to globally override the debug=”true” flag of all applications running on a machine (e.g. on a production server).
Update: deploying web apps with debug="true" is still bad, as you can read in Scott Hanselman’s recent blog post:
Here’s why debug=”true” is bad. Seriously, we’re not kidding.
- Overrides request execution timeout making it effectively infinite
- Disables both page and JIT compiler optimizations
- In 1.1, leads to excessive memory usage by the CLR for debug information tracking
- In 1.1, turns off batch compilation of dynamic pages, leading to 1 assembly per page.
- For VB.NET code, leads to excessive usage of WeakReferences (used for edit and continue support).
An important note: Contrary to what is sometimes believed, setting
retail=”true” in a element is not a direct antidote to
having debug=”true”!