接上篇，文章由北京北大青鳥學校學術部老師提供：
相關文章：ASP.NET中優(yōu)化性能的方法（三）
16. 適當?shù)厥褂霉舱Z言運行庫的垃圾回收器和自動內(nèi)存管理
北京北大青鳥學校提示：不要給每個請求分配過多內(nèi)存，因為這樣垃圾回收器將必須更頻繁地進行更多的工作。另外，不要讓不必要的指針指向對象，因為它們將使對象保持活動狀態(tài)，并且應盡量避免含 Finalize 方法的對象，因為它們在后面會導致更多的工作。特別是在 Finalize 調用中永遠不要釋放資源，因為資源在被垃圾回收器回收之前可能一直消耗著內(nèi)存。最后這個問題經(jīng)常會對 Web 服務器環(huán)境的性能造成毀滅性的打擊，因為在等待 Finalize 運行時，很容易耗盡某個特定的資源。
17. 如果有大型 Web 應用程序，可考慮執(zhí)行預批編譯
每當發(fā)生對目錄的第一次請求時都會執(zhí)行批編譯。如果目錄中的頁面沒有被分析并編譯，此功能會成批分析并編譯目錄中的所有頁面，以便更好地利用磁盤和內(nèi)存。如果這需要很長時間，則將快速分析并編譯單個頁面，以便請求能被處理。此功能帶給 ASP.NET 性能上的好處，因為它將許多頁面編譯為單個程序集。從已加載的程序集訪問一頁比每頁加載新的程序集要快。批編譯的缺點在于：如果服務器接收到許多對尚未編譯的頁面的請求，那么當 Web 服務器分析并編譯它們時，性能可能較差。
為解決這個問題，北京北大青鳥學校的建議是，可以執(zhí)行預批編譯。為此，只需在應用程序激活之前向它請求一個頁面，無論哪頁均可。然后，當用戶首次訪問您的站點時，頁面及其程序集將已被編譯。沒有簡單的機制可以知道批編譯何時發(fā)生。需一直等到 CPU 空閑或者沒有更多的編譯器進程(例如 csc.exe(C# 編譯器)或 vbc.exe(Visual Basic 編譯器))啟動。
還應盡量避免更改應用程序的 bin 目錄中的程序集。更改頁面會導致重新分析和編譯該頁，而替換 bin 目錄中的程序集則會導致完全重新批編譯該目錄。在包含許多頁面的大規(guī)模站點上，更好的辦法可能是根據(jù)計劃替換頁面或程序集的頻繁程度來設計不同的目錄結構。不常更改的頁面可以存儲在同一目錄中并在特定的時間進行預批編譯。經(jīng)常更改的頁面應在它們自己的目錄中(每個目錄最多幾百頁)以便快速編譯。Web 應用程序可以包含許多子目錄。批編譯發(fā)生在目錄級，而不是應用程序級。（北京北大青鳥學校）
18. 不要依賴代碼中的異常
因為異常大大地降低性能，所以不應該將它們用作控制正常程序流程的方式。如果有可能檢測到代碼中可能導致異常的狀態(tài)，請執(zhí)行這種操作。不要在處理該狀態(tài)之前捕獲異常本身。常見的方案包括：檢查 null，分配給將分析為數(shù)字值的 String 一個值，或在應用數(shù)學運算前檢查特定值。下面的示例演示可能導致異常的代碼以及測試是否存在某種狀態(tài)的代碼。兩者產(chǎn)生相同的結果。
try { result = 100 / num; } catch (Exception e) { result = 0; } // ...to this. if (num != 0) result = 100 / num; else result = 0;
（北京北大青鳥學校，未完待續(xù)）
