Configuration Settings that Impact Performance

When an ASP.NET page is visited for the first time (or the first time after it has changed), its declarative markup must be converted into a class and this class must be compiled. If the web application uses automatic compilation then the page's code-behind class needs to be compiled, too. You can configure an assortment of compilation options via the Web.config file's element.

The debug attribute is one of the most important attributes in the element. If the debug attribute is set to "true" then the compiled assemblies include debug symbols, which are needed when debugging an application in Visual Studio. But debug symbols increase the size of the assembly and impose additional memory requirements when running the code. Furthermore, when the debug attribute is set to "true" any content returned by WebResource.axd is not cached, meaning that each time a user visits a page they will need to re-download the static content returned by WebResource.axd.

Note: WebResource.axd is a built-in HTTP Handler introduced in ASP.NET 2.0 that server controls use to retrieve embedded resources, such as script files, images, CSS files, and other content. For more information on how WebResource.axd works and how you can use it to access embedded resources from your custom server controls, see Accessing Embedded Resources Through a URL Using WebResource.axd.

The element's debug attribute is usually set to "true" in the development environment. In fact, this attribute must be set to "true" in order to debug a web application; if you try to debug an ASP.NET application from Visual Studio and the debug attribute is set to "false", Visual Studio will display a message explaining that the application cannot be debugged until the debug attribute is set to "true" and will offer to make this change for you.

You should never have the debug attribute set to "true" in a production environment because of its impact on performance.