問題陳述：
確保在每個asp.net 應用中web.config里面在<compilation>節中的“debug=false”。這個在開發中的缺省設置是true，而且他是我們經常的犯的錯誤，把這個缺省設置部署到在生產環境中的實際應用。你沒有必要設置為true，因為它會導致內存的總開銷和低效率。
保留debug=true會導致什么問題？
當設置為true或者false，主要有3個主要的差別
1) asp.net 過期時間
2) 批量編譯
3) 代碼優化
asp.net 過期時間
當設置為debug=true時，asp.net 請求不會過期，這個會允許你用vs studio來按照你自己的步調來調式程序而不用擔心這個請求會突然消失。當然，在生產環境中，超時過期是確保請求不會被卡住，這就是針對第一個的理由。
批量編譯
簡單來說，當設置為true，我們不會進行批量編譯，而false 則會。
這是什么意思？
當一個 aspx、asax、ascx頁面第一次被請求，它會被編譯成一個dll程序集。這個程序集有一個類似3ks0rnwz.dll的名字（8個字符），里面保存的是實際的ascx、asax或aspx的類（不是code behind 的代碼），這個文件在C:"WINDOWS"Microsoft.NET"Framework"版本"Temporary ASP.NET Files文件夾的應用程序名下面。
那些code behind的類被編譯到程序集的主dll中，他和其他的dll一起放在應用程序的bin目錄下，拷貝映射到asp.net 臨時目錄。
回到3ks0rnwz.dll… 如果我們把debug設置為true，那么會為每個aspx、asax或ascx頁面創建一個dll，而且是debug模式的dll，所以如果你有100個頁面，那會創建100個程序集，他們會在頁面被請求的時候創建。
如果我們把debug設置為false，那會批量編譯。意思是第一次請求任何頁面的時候，會編譯整個應用程序，生成一個很大的dll，這是一個事實，但有些修正，用戶控件（ascx頁面）會被編譯成到一個分開的程序集中，和aspx頁面分離，而aspx頁面會分組按他們所引用的用戶控件分組編譯，global.asax也是分開編譯。編譯也是基於目錄的，即如果應用中還有子目錄，那子目錄也是單獨編譯，避免同名沖突，因為在可能有相同名字的aspx頁面在不同的目錄中。但總的來說，相比100個dll，你肯那個只有4 或5個dll。
因為代碼都是相同的，所以合在一起的dll合單獨的dll的大小並沒有很大的差別，但那有一個很大的…總體消耗，對每個dll而言。在dubug模式下編譯的dll有一個為了調試而需要的資源消耗。最重要的是，這些dll不會在內存中一個挨着一個排列着，所以，針對有很多的dll的情況，你會開始在虛擬內存中搞出碎片，這將會更難的找到足夠的空間來存儲托管堆，很有可能會導致內存異常。
另一種情況是，如果設置debug=false，你修改了一個aspx頁面，這個頁面就需要重新編譯，但這不會導致應用程序域（appdomain）重新加載，這樣整個程序就不會重新批量編譯，單個頁面會被單獨編譯，生成一個dll。所以不要在一個運行着的服務器上經常行的改變你的aspx頁面。
在machine.config中有一個配置選項，允許重新編譯多少個頁面而應用程序域不重啟動。缺省的是15，所以在有15個重新編譯行為之后，應用程序域會重新啟動，這個跟你修改web.config 或bin目錄導致應用程序域重啟一樣。
代碼優化
JIT為了能夠單步的調試代碼，並不能夠真的優化代碼，所以debug模式下的代碼性能就會比release模式的要差。
如何在內存dump文件找出這些？
要確定你的應用程序時候運行在debug模式下，在sos.dll中有一個很靈巧的命令是 !finddebugtrue，它會列出你需要的信息。
0:016> !finddebugtrue
Debug set to true for Runtime: 61b48dc, AppDomain: /MyDebugApplication
Debug set to true for Runtime: 1f50e6d8, AppDomain: /MemoryIssues
Total 16 HttpRuntime objects
要找出你忘記編譯成release模式的模塊，你可以運行 !finddebugmodules
0:016> !finddebugmodules
Loading all modules.
Searching for modules built in debug mode...
MyDebugApplication.dll built debug
MemoryIssues.dll built debug
fl4sq-9i.dll built debug
wepr1t3k.dll built debug
r9ocxl4m.dll built debug
zmaozzfb.dll built debug
Done Seaching
那些8個字母的dll是JIT引擎編譯的aspx頁面。
噢，前面我忘記了….當你從debug=true改變到debug=false時，把 asp.net 臨時目錄里的程序集刪除掉，這樣你不會有那些導致不會批量編譯的舊垃圾。
在asp.net 2.0中，在machine.config中有一個開關量，可以吧debug=true 關閉，所有有了他，你不必擔心那個應用程序是debug模式或不是。
<configuration>
<system.web>
<deployment retail=”true”/>
</system.web>
</configuration>
本文轉載自http://blog.csdn.net/snoopy83101/article/details/4545375
本人只是為了自己和看到此文字的人能加深記憶。。