debug=true in web.config = BAD thing?

Question

We\'re seeing lots of virtual memory fragmentation and out of memory errors and then it hits the 3GB limit.

The compilation debug is set to true in the web.config bu

Answer 1

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:

1. The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)
2. Code can execute slower (since some additional debug paths are enabled)
3. Much more memory is used within the application at runtime
4. 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 > 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"!