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