Asp.net web.config debug="true" performance bug?

Below is pasted from MSDN web site,

ASP.NET automatically detects any changes to Web.config files and applies the new configuration settings. You do not have to reboot or restart the server for changes to take effect.

Enabling debug mode will greatly affect the performance of your ASP.NET application. Remember to disable debug mode before you deploy a release application or conduct performance measurements.


OK, I was having some performance issue these days, I found debug elements were set to "true" in almost all the web.config files. I thought I could do something to improve the performance a little, so I changed them all to "false", and it seemed fine after my careless testing.

But boom! At the very beginning users went online, they found performance downgraded terribly on certain pages, in the past only a few seconds was needed, now every request was returned with a timeout error after about 30 seconds or so.

As we found in SQL server profiler, the culprit was a single sql statement with calling to a user defined function. If executed in Query Analyzer, the CPU was at single digit, "reads" at less than 100. But if executed via web pages, the CPU consumed was at 50K, the reads was at 6-7 millions. It seems index was not utilized when accessing via web pages.

We tried everthing we can to fix the timeout issue but all in vain after many frustrated hours. We tested the network connection between IIS server and database server, it was fine. We reduced records in related tables to only 20% as before, it didn't help. We extended "timeout" limit in every place we can find, IIS, web.config, helpless either. And so on, and so on.

Now I have no other way but to reconsider my changes to IIS, set them to debug="true" again, the world is in peace again. Therefore, may I so, contrary to what Microsoft declared, setting debut="true" actully improves performance?

However, there are still some doubts in my mind,
1. It affects only a single page yesterday, no other pages or applications are affected.
2. We tested on another backup IIS server with debug="true", it has the same problem.