debug=true in web.config = BAD thing?
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 but I get different answers from everyone i ask, does debug set to true cause each aspx to compile into random areas of ram thus fragmenting that ram and eventually causing out of memory problems?
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"!
The debug flag should be set to false in web.config, unless you actually need to debug the application.
Running in debug mode can increase the memory usage somewhat, but it's not likely case as severe problems as you are talking about. However, you should set it to false to elliminate the effect that it has, and see if you can notice any improvement.
When run in debug mode, the garbage collection works differently. The life time of variables is expanded from it's actual usage to the scope of the variable (to be able to show the value in the debugger). This makes some objects live longer before they are garbage collected.
The compiler doesn't optimize the code when compiling in debug mode, and also some extra nop instructions are added so that each code line has at least one instruction where a break point can be placed.
Throwing an exception takes considerably longer in debug mode. (However, normally the code should not throw exceptions that often.)