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

AFAIK "debug = true" not cause the situation you mentioned.

I had faced same problem with an ASP.NET application that created images on the fly.

so I think you have a problem with not disposed resources.

If you deploy your aspx files with code-behind files to server. It will be compiled once when the request comes to an aspx. then it will be stored to the cache until the file changes.

Answer 2

It absolutely could affect memory, just take a look at some of the perfmon counters and run a comparison with both configurations.

If your site has a lot of files I would be more concerned with disk io in the asp.net temp folder.

Couple Questions...

1. Do you have a lot of files in your App_Code?
2. Are you allowing the site to be updatable or are you publishing it?
3. If so is the site being updated frequently or is there a deployment process?
4. What is the hardware configuration?

Why not utilize multiple configurations?

Web.Debug.Config - Have debugging turned on Web.UAT.Config - Whatever your preference Web.Release.Config - Have Debugging turned off

This way you can minimize regression configuration errors like a developer checking a web.config in with debug="true"

Answer 3

On production systems always set Debug=false. As the flag suggests it should only be set to true when debugging a development system.

This flag has nothing to do with your memory fragmentation problem.

Answer 4

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

Answer 5

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 <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"!