ASP.NET性能優化小結(ASP.NET&C#)

時間 2019-11-13

標籤 asp.net asp 性能優化小結 asp.net&c 欄目 ASP 简体版

原文原文鏈接

ASP.NET:javascript

1、返回多個數據集html

　　檢查你的訪問數據庫的代碼，看是否存在着要返回屢次的請求。每次往返下降了你的應用程序的每秒可以響應請求的次數。經過在單個數據庫請求中返回多個結果集，能夠減小與數據庫通訊的時間，使你的系統具備擴展性，也能夠減小數據庫服務器響應請求的工做量。java

　　若是用動態的SQL語句來返回多個數據集，那用存儲過程來替代動態的SQL語句會更好些。是否把業務邏輯寫到存儲過程當中，這個有點爭議。可是我認爲，把業務邏輯寫到存儲過程裏面能夠限制返回結果集的大小，減少網絡數據的流量，在邏輯層也不用在過濾數據，這是一個好事情。程序員

　　用SqlCommand對象的ExecuteReader方法返回一個強類型的業務對象，再調用NextResult方法來移動數據集指針來定位數據集。返回多個ArrayList強類型對象。只從數據庫中返回你須要的數據能夠大大的減少你的服務器所耗用的內存。算法

2、對數據進行分頁數據庫

　　ASP.NET的DataGrid有一個很是有用的功能：分頁。若是DataGrid容許分頁，在某一時刻它只下載某一頁的數據，另外，它有一個數據分頁的濟覽導航欄，它讓你能夠選擇瀏覽某一頁，並且每次只下載一頁的數據。編程

　　可是它有一個小小的缺點，就是你必須把全部的數據都綁定到DataGrid中。也就是說，你的數據層必須返回全部的數據，而後DataGrid再根據當前頁過濾出當前頁所須要的數據顯示出來。若是有一個一萬條記錄的結果集要用DataGrid進行分頁，假設DataGrid每頁只顯示25條數據，那就意味着每次請求都有9975條數據都是要丟棄的。每次請求都要返回這麼大的數據集，對應用程序的性能影響是很是大的。windows

　　一個好的解決方案是寫一個分頁的存儲過程，例如對Northwind數據庫orders表的分頁存儲過程。你只須要傳當前頁碼，每頁顯示的條數兩個參數進來，存儲過程會返回相應的結果。數組

　　在服務器端，專門寫了一個分頁的控件來處理數據的分頁，在一個存儲過程裏面返回了兩個結果集：數據記錄總數和要求的結果集。瀏覽器

　　返回的記錄總數取決於要執行查詢，例如，一個where條件能夠限制返回的結果集的大小。由於在分頁界面中必需要根據數據集記錄的大小來計算總的頁數，因此必需要返回結果集的記錄數。例如，若是一共有1000000條記錄，若是用where條件就能夠過濾成只返回1000條記錄，存儲過程的分頁邏輯應該知道返回那些須要顯示的數據。

3、鏈接池

　　用TCP來鏈接你的應用程序與數據庫是一件昂貴的事情（很費時的事情），微軟的開發者能夠經過用鏈接池來反覆的使用數據庫的鏈接。比起每次請求都用TCP來連一次數據庫，鏈接池只有在不存在有效的鏈接時才新建一個TCP 鏈接。當關閉一個鏈接的時候，它會被放到池中，它仍然會保持與數據庫的鏈接，這樣就能夠減小與數據庫的TCP鏈接次數。

　　固然，你要注意那些忘記關的鏈接，你應在每次用完鏈接後立刻關閉它。要強調的是：不管什麼人說.net framework中的GC(垃圾收集器)總會在你用完鏈接對象後調用鏈接對象的Close或者Dispose方法顯式的關閉你的鏈接。不要指望CLR會在你想象的時間內關掉鏈接，雖然CLR最終都要銷燬對象和關閉邊接，可是咱們並不能肯定它到底會在何時作這些事情。

　　要用鏈接池優化，有兩條規則，第一，打開鏈接，處理數據，而後關閉鏈接。若是你必須在每次請求中屢次打開或關閉鏈接，這好過一直打開一個邊接，而後把它傳到各個方法中。第二，用相同的鏈接字符串（或者用相同的用戶標識，當你用集成認證的時候）。若是你沒有用相同的鏈接字符串，如你用基於登陸用戶的鏈接字符串，這將不能利用鏈接池的優化功能。若是你用的是集成的論證，由於用戶不少，因此你也不能充分利用鏈接池的優化功能。.NET CLR提供了一個數據性能計數器，它在咱們須要跟蹤程序性能特性的時候很是有用，固然也包括鏈接池的跟蹤了。

　　不管你的應用程序何時要連在另外一臺機子的資源，如數據庫，你都應該重點優化你連資源所花的時間，接收和發送數據的時間，以及往返回之間的次數。優化你的應用程序中的每個處理點（process hop），它是提升你的應用的性能的出發點。

　　應用程序層包含與數據層鏈接，傳送數據到相應的類的實例以及業務處理的邏輯。例如，在Community Server中，要組裝一個Forums或者Threads集合，而後應用業務邏輯，如受權，更重要的，這裏要完成緩存邏輯。

4、ASP.NET緩存API

　　在寫應用程序以前,你要作的第一件事是讓應用程序最大化的利用ASP.NET的緩存功能。

　　若是你的組件是要在Asp.net應用程序中運行，你只要把System.Web.dll引用到你的項目中就能夠了。而後用 HttpRuntime.Cache屬性就可訪問Cache了（也能夠經過Page.Cache或HttpContext.Cache訪問）。

　　有如下幾條緩存數據的規則。第一，數據可能會被頻繁的被使用，這種數據能夠緩存。第二，數據的訪問頻率很是高，或者一個數據的訪問頻率不高，可是它的生存週期很長，這樣的數據最好也緩存起來。第三是一個經常被忽略的問題，有時候咱們緩存了太多數據，一般在一臺X86的機子上，若是你要緩存的數據超過 800M的話，就會出現內存溢出的錯誤。因此說緩存是有限的。換名話說，你應該估計緩存集的大小，把緩存集的大小限制在10之內，不然它可能會出問題。在 Asp.net中，若是緩存過大的話也會報內存溢出錯誤，特別是若是緩存大的DataSet對象的時候。

這裏有幾個你必須瞭解的重要的緩存機制。首先是緩存實現了「最近使用」原則（ a least-recently-used algorithm），當緩存少的時候，它會自動的強制清除那些無用的緩存。其次「條件依賴」強制清除原則（expiration dependencies），條件能夠是時間，關鍵字和文件。以時間做爲條件是最經常使用的。在asp.net2.0中增長一更強的條件，就是數據庫條件。當數據庫中的數據發生變化時，就會強制清除緩存　　

5、預請求緩存

　　在前面，咱們只對某些地方做了一個小小的性能改進也能夠得到大的性能提高，用預請求緩存來提高程序的性能是很不錯的。

　　雖然Cache API設計成用來保存某段時間的數據，而預請求緩存只是保存某個時期的某個請求的內容。若是某個請求的訪問頻率高，並且這個請求只須要提取，應用，修改或者更新數據一次。那麼就能夠預緩存該請求。咱們舉個例子來講明。

　　在BS的論壇應用程序中，每個頁面的服務器控件都要求獲得用於決定它的皮膚（skin）的自定義的數據，以決定用哪一個樣式表及其它的一些個性化的東西。這裏面的某些數據可能要長時間的保存，有些時間則否則，如控件的skin數據，它只須要應用一次，然後就能夠一直使用。

　　要實現預請求緩存，用Asp.net 的HttpContext類，HttpContext類的實例在每個請求中建立，在請求期間的任何地方均可以經過 HttpContext.Current屬性訪問。HttpContext類有一個Items集合屬性，在請求期間全部的對象和數據都被添加到這個集合中緩存起來。和你用Cache緩存訪問頻率高數據同樣，你能夠用HttpContext.Items緩存那些每一個請求都要用到的基礎數據。它背後的邏輯很簡單：咱們向HttpContext.Items中添加一個數據，而後再從它裏面讀出數據。

6、後臺處理

　　經過上面的方法你的應用程序應該運行得很快了，是否是？可是在某些時候，程序中的一次請求中可能要執行一個很是耗時的任務。如發送郵件或者是檢查提交的數據的正確性等。

　　當咱們把asp.net Forums 1.0集成在CS中的時侯，發現提交一個新的帖子的時候會很是的慢。每次新增一個帖子的時侯，應用程序首先要檢查這個帖子是否是重複提的，而後用「badword」過濾器來過濾，檢查圖片附加碼，做帖子的索引，把它添加到合適的隊列中，驗證它的附件，最後，發郵件到它的訂閱者郵件箱中。顯然，這個工做量很大。

　　結果是它把大量的時間都花在作索引和發送郵件中了。作帖子的索引是一項很耗時的操做，而發郵件給訂閱都須要鏈接到SMTP服務，而後給每個訂閱者都發一封郵件，隨着訂閱用戶的增長，發送郵件的時間會更長。

　　索引和發郵件並不須要在每次請求時觸發，理想狀態下，咱們想要批量的處理這些操做，每次只發25封郵件或者每隔5分鐘把全部的要發的新郵件發一次。咱們決定使用與數據庫原型緩存同樣的代碼，可是失敗了，因此又不得不回到VS.NET 2005。

　　咱們在System.Threading命名空間下找到了Timer類，這個類很是有用，但卻不多有人知道，Web開發人員則更少有人知道了。一旦他建了該類的實例，每隔一個指定的時間，Timer類就會從線程池中的一個線程中調用指定的回調函數。這意味着你的asp.net應用程序能夠在沒有請求的時候也能夠運行。這就是後以處理的解決方案。你就可讓作索引和發郵件工做在後臺運行，而不是在每次請求的時候必須執行。

　　後臺運行的技術有兩個問題，第一是，當你的應用程序域卸載後，Timer類實例就會中止運行了。也就是不會調用回調方法了。另外，由於CLR的每一個進程中都有許多的線程在運行，你將很難讓Timer得到一個線程來執行它，或者能執行它，但會延時。Asp.net層要儘可能少的使用這種技術，以減小進程中線程的數量，或者只讓請求用一小部分的線程。固然若是你有大量的異步工做的話，那就只能用它了。

7、頁面輸出緩存和代理服務

　　 Asp.net是你的界面層（或者說應該是），它包含頁面，用戶控件，服務器控件（HttpHandlers 和HttpModules）以及它們生成的內容。若是你有一個Asp.net頁面用來輸出html，xml,imgae或者是其它的數據，對每個請求你都用代碼來生成相同的輸出內容，你就頗有必要考慮用頁面輸出緩存了。

只要簡單的把下面的這一行代碼複製到你的頁面中就能夠實現了：

<%@ PageOutputCache VaryByParams=」none」 Duration=」60」 %>

就能夠有效的利用第一次請求裏生成的頁面輸出緩存內容，60秒後從新生成一道頁面內容。這種技術其實也是運用一些低層的Cache API來實現。用頁面輸出緩存有幾個參數能夠配置，如上面所說的VaryByParams參數，該參數表示何時觸發重輸出的條件，也能夠指定在 Http Get或Http Post 請求模式下緩存輸出。例如當咱們設置該參數爲VaryByParams=」Report」的時候，default.aspx?Report=1或者 default.aspx?Report=2請求的輸出都會被緩存起來。參數的值能夠是多個用分號隔開參數。

　　許多人都沒有意識到當用頁面輸出緩存的時候，asp.net也會生成HTTP頭集（HTTP Header）保存在下游的緩存服務器中，這些信息能夠用於Microsoft Internet安全性中以及加速服務器的響應速度。當HTTP緩存的頭被重置時，請求的內容會被緩在網絡資源中，當客戶端再次請求該內容時，就不會再從源服務器上得到內容了，而直接從緩存中得到內容。

　　雖然用頁面輸出緩存不提升你的應用程序性能，可是它能減小了從的服務器中加載已緩存頁面內容的次數。固然，這僅限於緩存匿名用戶能夠訪問的頁面。由於一旦頁面被緩存後，就不能再執行受權操做了。

8、用IIS6.0的Kernel Caching

　　若是你的應用程序沒用運行在IIS6.0(windows server 2003)中，那麼你就失去了一些很好的提升應用程序性能的方法。在第七個方法中，我講了用頁面輸出緩存提升應用程序的性能的方法。在IIS5.0中，當一個請求到來到IIS後，IIS會把它轉給asp.net，當應用了頁面輸出緩存時，ASP.NET中的HttpHandler會接到該請求，HttpHandler從緩存中把內容取出來並返回。

　　若是你用的是IIS6.0，它有一個很是好的功能就是Kernel Caching，並且你沒必要修改asp.net程序中任何代碼。當asp.net接到一個已緩存的請求，IIS的Kernel Cache會從緩存中獲得它的一份拷貝。當從網絡中傳來一個請求的時，Kernel層會獲得該請求，若是該請求被緩存起來了，就直接把緩存的數據返回，這樣就完工了。這就意味着當你用IIS的Kernel Caching來緩存頁面輸出時，你將得到不可置信的性能提高。在開發VS.NET 2005的 asp.net時有一點，我是專門負asp.net性能的程序經理，個人程序員用了這個方法，我看了全部日報表數據，發現用kernel model caching的結果老是最快的。它們的一個共同的特徵就是網絡的請求和響應量很大,但IIS只佔用了5%的CPU資源。這是使人驚奇的。有許多讓你使用用IIS6.0的理由，但kernel cashing是最好的一個。

9、用Gzip壓縮數據

　　除非你的CPU佔用率過高了，纔有必要用提高服務器性能的技巧。用gzip壓縮數據的方法能夠減小你發送到服務端的數據量，也能夠提升頁面的運行速度，同時也減小了網絡的流量。怎麼樣更好的壓縮數據取決於你要發送的數據，還有就是客戶端的瀏覽器支不支持（IIS把用gzip壓縮後的數據發送到客戶端，客戶端要支持gzip 才能解析，IE6.0和Firefox都支持）。這樣你的服務器每秒能多響應一些請求，一樣，你也減小了發送響應的數據量，也就能多發送一些請求了。

　　好消息，gzip壓縮已經被集成在IIS6.0中了，它比IIS5.0中gzip更好。不幸的是，在IIS6.0中啓用gzip壓縮，你不能在 IIS6.0的屬性對話中設置。IIS開發團隊把gzip壓縮功能開發出來了，但他們卻忘了在管理員窗口中讓管理員能很方便的啓用它。要啓用gzip壓縮，你只能深刻IIS6.0的xml配置文件中修改它的配置。

　　除了閱讀本文之外看看Brad Wilson寫的 IIS6 壓縮一文：http://www.dotnetdevs.com/articles/IIS6compression.aspx；另外還有一篇介紹 aspx壓縮基礎知識的文章，Enable ASPX Compression in IIS。可是要注意，在IIS6中動態壓縮和kernel cashing是互斥的。

10、服務器控件的ViewState

　　ViewState是asp.net中的一個特性，它用於把生成頁面要用的一狀態值保存在一個隱藏域中。當頁面被回傳到服務器時，服務器要解析，校驗和應用ViewState中的數據以還原頁面的控件樹。ViewState是一個很是有用的特性，它能持久化客戶端的狀態而不用cookie或者服務器的內存。大部分的服務器控件都是用ViewState 來持久化那些在頁面中與用戶交互的元素的狀態值。例如，用以保存用於分頁的當前頁的頁碼。

　　用ViewState會帶來一些負面的影響。首先，它加大的服務器的響應和請求的時間。其次，每次回傳時都增長了序列化和反序列化數據的時間。最後，它還消耗了服務器更多的內存。

　　許多的服務器控件很趨於使用ViewState，如DataGrid，而有時候是沒有必須使用的。默認狀況下是容許使用ViewState的，若是你不想使用ViewState的話，你能夠在控件或頁面級別把關閉它。在控件中，你只要把EnableViewState屬性設爲False就能夠了；你也能夠在頁面中設置，使它的範圍擴展到整個頁面中： <%@ Page EnableViewState=」false」 %> 若是頁面無需回傳或者每次請求頁面只是呈現控件。你就應該在頁面級別中把ViewState關掉。

1. C#語言方面

1.1 垃圾回收
　垃圾回收解放了手工管理對象的工做，提升了程序的健壯性，但反作用就是程序代碼可能對於對象建立變得隨意。
　1.1.1 避免沒必要要的對象建立
　因爲垃圾回收的代價較高，因此C#程序開發要遵循的一個基本原則就是避免沒必要要的對象建立。如下列舉一些常見的情形。
　1.1.1.1 避免循環建立對象 ★
　若是對象並不會隨每次循環而改變狀態，那麼在循環中反覆建立對象將帶來性能損耗。高效的作法是將對象提到循環外面建立。
　1.1.1.2 在須要邏輯分支中建立對象
　若是對象只在某些邏輯分支中才被用到，那麼應只在該邏輯分支中建立對象。
　1.1.1.3 使用常量避免建立對象
　程序中不該出現如 new Decimal(0) 之類的代碼，這會致使小對象頻繁建立及回收，正確的作法是使用Decimal.Zero常量。咱們有設計本身的類時，也能夠學習這個設計手法，應用到相似的場景中。
　1.1.1.4 使用StringBuilder作字符串鏈接

1.1.2 不要使用空析構函數 ★
　若是類包含析構函數，由建立對象時會在 Finalize 隊列中添加對象的引用，以保證當對象沒法可達時，仍然能夠調用到 Finalize 方法。垃圾回收器在運行期間，會啓動一個低優先級的線程處理該隊列。相比之下，沒有析構函數的對象就沒有這些消耗。若是析構函數爲空，這個消耗就毫無心義，只會致使性能下降！所以，不要使用空的析構函數。
　在實際狀況中，許多曾在析構函數中包含處理代碼，但後來由於種種緣由被註釋掉或者刪除掉了，只留下一個空殼，此時應注意把析構函數自己註釋掉或刪除掉。
　1.1.3 實現 IDisposable 接口
　垃圾回收事實上只支持託管內在的回收，對於其餘的非託管資源，例如 Window GDI 句柄或數據庫鏈接，在析構函數中釋放這些資源有很大問題。緣由是垃圾回收依賴於內在緊張的狀況，雖然數據庫鏈接可能已瀕臨耗盡，但若是內存還很充足的話，垃圾回收是不會運行的。
　 C#的 IDisposable 接口是一種顯式釋放資源的機制。經過提供 using 語句，還簡化了使用方式（編譯器自動生成 try ... finally 塊，並在 finally 塊中調用 Dispose 方法）。對於申請非託管資源對象，應爲其實現 IDisposable 接口，以保證資源一旦超出 using 語句範圍，即獲得及時釋放。這對於構造健壯且性能優良的程序很是有意義！
爲防止對象的 Dispose 方法不被調用的狀況發生，通常還要提供析構函數，二者調用一個處理資源釋放的公共方法。同時，Dispose 方法應調用 System.GC.SuppressFinalize(this)，告訴垃圾回收器無需再處理 Finalize 方法了。

1.2 String 操做
　1.2.1 使用 StringBuilder 作字符串鏈接
　 String 是不變類，使用 + 操做鏈接字符串將會致使建立一個新的字符串。若是字符串鏈接次數不是固定的，例如在一個循環中，則應該使用 StringBuilder 類來作字符串鏈接工做。由於 StringBuilder 內部有一個 StringBuffer ，鏈接操做不會每次分配新的字符串空間。只有當鏈接後的字符串超出 Buffer 大小時，纔會申請新的 Buffer 空間。典型代碼以下：StringBuilder sb = new StringBuilder( 256 );
for ( int i = 0 ; i < Results.Count; i ++ )
{
sb.Append (Results[i]);
}

若是鏈接次數是固定的而且只有幾回，此時應該直接用 + 號鏈接，保持程序簡潔易讀。實際上，編譯器已經作了優化，會依據加號次數調用不一樣參數個數的 String.Concat 方法。例如：String str = str1 + str2 + str3 + str4;
　會被編譯爲 String.Concat(str1, str2, str3, str4)。該方法內部會計算總的 String 長度，僅分配一次，並不會如一般想象的那樣分配三次。做爲一個經驗值，當字符串鏈接操做達到 10 次以上時，則應該使用 StringBuilder。

　這裏有一個細節應注意：StringBuilder 內部 Buffer 的缺省值爲 16 ，這個值實在過小。按 StringBuilder 的使用場景，Buffer 確定得從新分配。經驗值通常用 256 做爲 Buffer 的初值。固然，若是能計算出最終生成字符串長度的話，則應該按這個值來設定 Buffer 的初值。使用 new StringBuilder(256) 就將 Buffer 的初始長度設爲了256。
　1.2.2 避免沒必要要的調用 ToUpper 或 ToLower 方法
　String是不變類，調用ToUpper或ToLower方法都會致使建立一個新的字符串。若是被頻繁調用，將致使頻繁建立字符串對象。這違背了前面講到的「避免頻繁建立對象」這一基本原則。
　例如，bool.Parse方法自己已是忽略大小寫的，調用時不要調用ToLower方法。
　另外一個很是廣泛的場景是字符串比較。高效的作法是使用 Compare 方法，這個方法能夠作大小寫忽略的比較，而且不會建立新字符串。
　還有一種狀況是使用 HashTable 的時候，有時候沒法保證傳遞 key 的大小寫是否符合預期，每每會把 key 強制轉換到大寫或小寫方法。實際上 HashTable 有不一樣的構造形式，徹底支持採用忽略大小寫的 key: new HashTable(StringComparer.OrdinalIgnoreCase)。
　1.2.3 最快的空串比較方法
　將String對象的Length屬性與0比較是最快的方法：if (str.Length == 0)
　其次是與String.Empty常量或空串比較：if (str == String.Empty)或if (str == "")
　注：C#在編譯時會將程序集中聲明的全部字符串常量放到保留池中（intern pool），相同常量不會重複分配。

1.3 多線程

1.3.1 線程同步
　線程同步是編寫多線程程序須要首先考慮問題。C#爲同步提供了 Monitor、Mutex、AutoResetEvent 和 ManualResetEvent 對象來分別包裝 Win32 的臨界區、互斥對象和事件對象這幾種基礎的同步機制。C#還提供了一個lock語句，方便使用，編譯器會自動生成適當的 Monitor.Enter 和 Monitor.Exit 調用。
　1.3.1.1 同步粒度
　同步粒度能夠是整個方法，也能夠是方法中某一段代碼。爲方法指定 MethodImplOptions.Synchronized 屬性將標記對整個方法同步。例如：[MethodImpl(MethodImplOptions.Synchronized)]
public static SerialManager GetInstance()
{
if (instance == null )
{
instance = new SerialManager();
}
return instance;
}

一般狀況下，應減少同步的範圍，使系統得到更好的性能。簡單將整個方法標記爲同步不是一個好主意，除非能肯定方法中的每一個代碼都須要受同步保護。
　1.3.1.2 同步策略
　使用 lock 進行同步，同步對象能夠選擇 Type、this 或爲同步目的專門構造的成員變量。
　避免鎖定Type★
　鎖定Type對象會影響同一進程中全部AppDomain該類型的全部實例，這不只可能致使嚴重的性能問題，還可能致使一些沒法預期的行爲。這是一個很不好的習慣。即使對於一個只包含static方法的類型，也應額外構造一個static的成員變量，讓此成員變量做爲鎖定對象。
　避免鎖定 this
　鎖定 this 會影響該實例的全部方法。假設對象 obj 有 A 和 B 兩個方法，其中 A 方法使用 lock(this) 對方法中的某段代碼設置同步保護。如今，由於某種緣由，B 方法也開始使用 lock(this) 來設置同步保護了，而且可能爲了徹底不一樣的目的。這樣，A 方法就被幹擾了，其行爲可能沒法預知。因此，做爲一種良好的習慣，建議避免使用 lock(this) 這種方式。
　使用爲同步目的專門構造的成員變量
　這是推薦的作法。方式就是 new 一個 object 對象，該對象僅僅用於同步目的。
　若是有多個方法都須要同步，而且有不一樣的目的，那麼就能夠爲些分別創建幾個同步成員變量。

1.3.1.4 集合同步
　C#爲各類集合類型提供了兩種方便的同步機制：Synchronized 包裝器和 SyncRoot 屬性。
// Creates and initializes a new ArrayList
ArrayList myAL = new ArrayList();
myAL.Add( " The " );
myAL.Add( " quick " );
myAL.Add( " brown " );
myAL.Add( " fox " );

// Creates a synchronized wrapper around the ArrayList
ArrayList mySyncdAL = ArrayList.Synchronized(myAL);

調用 Synchronized 方法會返回一個可保證全部操做都是線程安全的相同集合對象。考慮 mySyncdAL[0] = mySyncdAL[0] + "test" 這一語句，讀和寫一共要用到兩個鎖。通常講，效率不高。推薦使用 SyncRoot 屬性，能夠作比較精細的控制。

1.3.2 使用 ThreadStatic 替代 NameDataSlot ★
　存取 NameDataSlot 的 Thread.GetData 和 Thread.SetData 方法須要線程同步，涉及兩個鎖：一個是 LocalDataStore.SetData 方法須要在 AppDomain 一級加鎖，另外一個是 ThreadNative.GetDomainLocalStore 方法須要在 Process 一級加鎖。若是一些底層的基礎服務使用了 NameDataSlot，將致使系統出現嚴重的伸縮性問題。
　規避這個問題的方法是使用 ThreadStatic 變量。示例以下：public sealed class InvokeContext
{
[ThreadStatic]
private static InvokeContext current;
private Hashtable maps = new Hashtable();
}

1.3.3 多線程編程技巧
　1.3.3.1 使用 Double Check 技術建立對象internal IDictionary KeyTable
{
get
{
if ( this ._keyTable == null )
{
lock ( base ._lock)
{
if ( this ._keyTable == null )
{
this ._keyTable = new Hashtable();
}
}
}
return this ._keyTable;
}
}

建立單例對象是很常見的一種編程狀況。通常在 lock 語句後就會直接建立對象了，但這不夠安全。由於在 lock 鎖定對象以前，可能已經有多個線程進入到了第一個 if 語句中。若是不加第二個 if 語句，則單例對象會被重複建立，新的實例替代掉舊的實例。若是單例對象中已有數據不容許被破壞或者別的什麼緣由，則應考慮使用 Double Check 技術。

1.4 類型系統
　1.4.1 避免無心義的變量初始化動做
　CLR保證全部對象在訪問前已初始化，其作法是將分配的內存清零。所以，不須要將變量從新初始化爲0、false或null。
　須要注意的是：方法中的局部變量不是從堆而是從棧上分配，因此C#不會作清零工做。若是使用了未賦值的局部變量，編譯期間即會報警。不要由於有這個印象而對全部類的成員變量也作賦值動做，二者的機理徹底不一樣！
　1.4.2 ValueType 和 ReferenceType

1.4.2.1 以引用方式傳遞值類型參數
　值類型從調用棧分配，引用類型從託管堆分配。當值類型用做方法參數時，默認會進行參數值複製，這抵消了值類型分配效率上的優點。做爲一項基本技巧，以引用方式傳遞值類型參數能夠提升性能。
　1.4.2.2 爲 ValueType 提供 Equals 方法
　 .net 默認實現的 ValueType.Equals 方法使用了反射技術，依靠反射來得到全部成員變量值作比較，這個效率極低。若是咱們編寫的值對象其 Equals 方法要被用到（例如將值對象放到 HashTable 中），那麼就應該重載 Equals 方法。public struct Rectangle
{
public double Length;
public double Breadth;
public override bool Equals ( object ob)
{
if (ob is Rectangle)
return Equels ((Rectangle)ob))
else
return false ;
}
private bool Equals (Rectangle rect)
{
return this .Length == rect.Length && this .Breadth == rect.Breach;
}
}

1.4.2.3 避免裝箱和拆箱
　C#能夠在值類型和引用類型之間自動轉換，方法是裝箱和拆箱。裝箱須要從堆上分配對象並拷貝值，有必定性能消耗。若是這一過程發生在循環中或是做爲底層方法被頻繁調用，則應該警戒累計的效應。
　一種常常的情形出如今使用集合類型時。例如：ArrayList al = new ArrayList();
for ( int i = 0 ; i < 1000 ; i ++ )
{
al.Add(i); // Implicitly boxed because Add() takes an object
}
int f = ( int )al[ 0 ]; // The element is unboxed

1.5 異常處理
　異常也是現代語言的典型特徵。與傳統檢查錯誤碼的方式相比，異常是強制性的（不依賴因而否忘記了編寫檢查錯誤碼的代碼）、強類型的、並帶有豐富的異常信息（例如調用棧）。
　1.5.1 不要吃掉異常★
　關於異常處理的最重要原則就是：不要吃掉異常。這個問題與性能無關，但對於編寫健壯和易於排錯的程序很是重要。這個原則換一種說法，就是不要捕獲那些你不能處理的異常。
　吃掉異常是極很差的習慣，由於你消除了解決問題的線索。一旦出現錯誤，定位問題將很是困難。除了這種徹底吃掉異常的方式外，只將異常信息寫入日誌文件但並不作更多處理的作法也一樣不妥。
　1.5.2 不要吃掉異常信息★
　有些代碼雖然拋出了異常，但卻把異常信息吃掉了。
　爲異常披露詳盡的信息是程序員的職責所在。若是不能在保留原始異常信息含義的前提下附加更豐富和更人性化的內容，那麼讓原始的異常信息直接展現也要強得多。千萬不要吃掉異常。
　1.5.3 避免沒必要要的拋出異常
　拋出異常和捕獲異常屬於消耗比較大的操做，在可能的狀況下，應經過完善程序邏輯避免拋出沒必要要沒必要要的異常。與此相關的一個傾向是利用異常來控制處理邏輯。儘管對於極少數的狀況，這可能得到更爲優雅的解決方案，但一般而言應該避免。
　1.5.4 避免沒必要要的從新拋出異常
　若是是爲了包裝異常的目的（即加入更多信息後包裝成新異常），那麼是合理的。可是有很多代碼，捕獲異常沒有作任何處理就再次拋出，這將無謂地增長一次捕獲異常和拋出異常的消耗，對性能有傷害。

1.6 反射
　反射是一項很基礎的技術，它將編譯期間的靜態綁定轉換爲延遲到運行期間的動態綁定。在不少場景下（特別是類框架的設計），能夠得到靈活易於擴展的架構。但帶來的問題是與靜態綁定相比，動態綁定會對性能形成較大的傷害。
　1.6.1 反射分類
　 type comparison ：類型判斷，主要包括 is 和 typeof 兩個操做符及對象實例上的 GetType 調用。這是最輕型的消耗，能夠無需考慮優化問題。注意 typeof 運算符比對象實例上的 GetType 方法要快，只要可能則優先使用 typeof 運算符。
　member enumeration ：成員枚舉，用於訪問反射相關的元數據信息，例如Assembly.GetModule、Module.GetType、Type對象上的 IsInterface、IsPublic、GetMethod、GetMethods、GetProperty、GetProperties、 GetConstructor調用等。儘管元數據都會被CLR緩存，但部分方法的調用消耗仍很是大，不過這類方法調用頻度不會很高，因此整體看性能損失程度中等。
　member invocation：成員調用，包括動態建立對象及動態調用對象方法，主要有Activator.CreateInstance、Type.InvokeMember等。
　1.6.2 動態建立對象
　C#主要支持 5 種動態建立對象的方式：
　　1. Type.InvokeMember
　　2. ContructorInfo.Invoke
　　3. Activator.CreateInstance(Type)
　　4. Activator.CreateInstance(assemblyName, typeName)
　　5. Assembly.CreateInstance(typeName)
　最快的是方式 3 ，與 Direct Create 的差別在一個數量級以內，約慢 7 倍的水平。其餘方式，至少在 40 倍以上，最慢的是方式 4 ，要慢三個數量級。
　1.6.3 動態方法調用
　方法調用分爲編譯期的早期綁定和運行期的動態綁定兩種，稱爲Early-Bound Invocation和Late-Bound Invocation。Early-Bound Invocation可細分爲Direct-call、Interface-call和Delegate-call。Late-Bound Invocation主要有Type.InvokeMember和MethodBase.Invoke，還能夠經過使用LCG（Lightweight Code Generation）技術生成IL代碼來實現動態調用。
　從測試結果看，相比Direct Call，Type.InvokeMember要接近慢三個數量級；MethodBase.Invoke雖然比Type.InvokeMember要快三倍，但比Direct Call仍慢270倍左右。可見動態方法調用的性能是很是低下的。咱們的建議是：除非要知足特定的需求，不然不要使用！
　1.6.4 推薦的使用原則
　模式
　　1．若是可能，則避免使用反射和動態綁定
　　2．使用接口調用方式將動態綁定改造爲早期綁定
　　3．使用Activator.CreateInstance(Type)方式動態建立對象
　　4．使用typeof操做符代替GetType調用
　反模式
　　1．在已得到Type的狀況下，卻使用Assembly.CreateInstance(type.FullName)

1.7 基本代碼技巧
　這裏描述一些應用場景下，能夠提升性能的基本代碼技巧。對處於關鍵路徑的代碼，進行這類的優化仍是頗有意義的。普通代碼能夠不作要求，但養成一種好的習慣也是有意義的。
　1.7.1 循環寫法
　能夠把循環的判斷條件用局部變量記錄下來。局部變量每每被編譯器優化爲直接使用寄存器，相對於普通從堆或棧中分配的變量速度快。若是訪問的是複雜計算屬性的話，提高效果將更明顯。for (int i = 0, j = collection.GetIndexOf(item); i < j; i++)
　須要說明的是：這種寫法對於CLR集合類的Count屬性沒有意義，緣由是編譯器已經按這種方式作了特別的優化。
　1.7.2 拼裝字符串
　拼裝好以後再刪除是很低效的寫法。有些方法其循環長度在大部分狀況下爲1，這種寫法的低效就更爲明顯了：public static string ToString(MetadataKey entityKey)
{
string str = "" ;
object [] vals = entityKey.values;
for ( int i = 0 ; i < vals.Length; i ++ )
{
str += " , " + vals[i].ToString();
}
return str == "" ? "" : str.Remove( 0 , 1 );
}

推薦下面的寫法：if (str.Length == 0 )
str = vals[i].ToString();
else
str += " , " + vals[i].ToString();

其實這種寫法很是天然，並且效率很高，徹底不須要用個Remove方法繞來繞去。
　1.7.3 避免兩次檢索集合元素
　獲取集合元素時，有時須要檢查元素是否存在。一般的作法是先調用ContainsKey（或Contains）方法，而後再獲取集合元素。這種寫法很是符合邏輯。
　但若是考慮效率，能夠先直接獲取對象，而後判斷對象是否爲null來肯定元素是否存在。對於Hashtable，這能夠節省一次GetHashCode調用和n次Equals比較。

以下面的示例：public IData GetItemByID(Guid id)
{
IData data1 = null ;
if ( this .idTable.ContainsKey(id.ToString())
{
data1 = this .idTable[id.ToString()] as IData;
}
return data1;
}

其實徹底可用一行代碼完成：return this.idTable[id] as IData;
　1.7.4 避免兩次類型轉換
　考慮以下示例，其中包含了兩處類型轉換： if (obj is SomeType)
{
SomeType st = (SomeType)obj;
st.SomeTypeMethod();
}

效率更高的作法以下：SomeType st = obj as SomeType;
if (st != null )
{
st.SomeTypeMethod();
}

1.8 Hashtable
　 Hashtable是一種使用很是頻繁的基礎集合類型。須要理解影響 Hashtable的效率有兩個因素：一是散列碼（GetHashCode方法），二是等值比較（Equals方法）。Hashtable首先使用鍵的散列碼將對象分佈到不一樣的存儲桶中，隨後在該特定的存儲桶中使用鍵的Equals方法進行查找。
　良好的散列碼是第一位的因素，最理想的狀況是每一個不一樣的鍵都有不一樣的散列碼。Equals方法也很重要，由於散列只須要作一次，而存儲桶中查找鍵可能須要作屢次。從實際經驗看，使用Hashtable時，Equals方法的消耗通常會佔到一半以上。

System.Object 類提供了默認的GetHashCode實現，使用對象在內存中的地址做爲散列碼。咱們遇到過一個用Hashtable來緩存對象的例子，每次根據傳遞的OQL表達式構造出一個ExpressionList對象，再調用 QueryCompiler的方法編譯獲得CompiledQuery對象。以ExpressionList對象和CompiledQuery對象做爲鍵值對存儲到Hashtable中。ExpressionList對象沒有重載GetHashCode實現，其超類ArrayList也沒有，這樣最後用的就是System.Object類的GetHashCode實現。因爲ExpressionList對象會每次構造，所以它的HashCode每次都不同，因此這個CompiledQueryCache根本就沒有起到預想的做用。這個小小的疏漏帶來了重大的性能問題，因爲解析OQL表達式頻繁發生，致使 CompiledQueryCache不斷增加，形成服務器內存泄漏！解決這個問題的最簡單方法就是提供一個常量實現，例如讓散列碼爲常量0。雖然這會導致全部對象匯聚到同一個存儲桶中，效率不高，但至少能夠解決掉內存泄漏問題。固然，最終仍是會實現一個高效的GetHashCode方法的。
　以上介紹這些Hashtable機理，主要是但願你們理解：若是使用Hashtable，你應該檢查一下對象是否提供了適當的GetHashCode和Equals方法實現。不然，有可能出現效率不高或者與預期行爲不符的狀況。

　2. Ado.Net

2.1 應用Ado.net的一些思考原則
　　1. 根據數據使用的方式來設計數據訪問層
　　2. 緩存數據，避免沒必要要的操做
　　3. 使用服務賬戶進行鏈接
　　4. 必要時申請，儘早釋放
　　5. 關閉可關閉的資源
　　6. 減小往返
　　7. 僅返回須要的數據
　　8. 選擇適當的事務類型
　　9. 使用存儲過程

2.2 Connection
　數據庫鏈接是一種共享資源，而且打開和關閉的開銷較大。Ado.net默認啓用了鏈接池機制，關閉鏈接不會真的關閉物理鏈接，而只是把鏈接放回到鏈接池中。由於池中共享的鏈接資源始終是有限的，若是在使用鏈接後不盡快關閉連接，那麼就有可能致使申請鏈接的線程被阻塞住，影響整個系統的性能表現。
　2.2.1 在方法中打開和關閉鏈接
　這個原則有幾層含義：
　　1. 主要目的是爲了作到必要時申請和儘早釋放
　　2. 不要在類的構造函數中打開鏈接、在析構函數中釋放鏈接。由於這將依賴於垃圾回收，而垃圾回收只受內存影響，回收時機不定
　　3. 不要在方法之間傳遞鏈接，這每每致使鏈接保持打開的時間過長

這裏強調一下在方法之間傳遞鏈接的危害：曾經在壓力測試中遇到過一個測試案例，當增大用戶數的時候，這個案例要比別的案例早好久就用掉鏈接池中的全部鏈接。經分析，就是由於A方法把一個打開的鏈接傳遞到了B方法，而B方法又調用了一個自行打開和關閉鏈接的C方法。在 A方法的整個運行期間，它至少須要佔用兩條鏈接纔可以成功工做，而且其中的一條鏈接佔用時間還特別長，因此形成鏈接池資源緊張，影響了整個系統的可伸縮性！

2.2.2 顯式關閉鏈接
　Connection對象自己在垃圾回收時能夠被關閉，而依賴垃圾回收是很很差的策略。推薦使用using語句顯式關閉鏈接，以下例：using (SqlConnection conn = new SqlConnection(connString))
{
conn.Open();

} // Dispose is automatically called on the conn variable here

2.2.3 確保鏈接池啓用
　Ado.net是爲每一個不一樣的鏈接串創建鏈接池，所以應該確保鏈接串不會出現與具體用戶相關的信息。另外，要注意鏈接串是大小寫敏感的。
　2.2.4 不要緩存鏈接
　例如，把鏈接緩存到Session或Application中。在啓用鏈接池的狀況下，這種作法沒有任何意義。
　2.3 Command
　2.3.1 使用ExecuteScalar和ExecuteNonQuery
　若是想返回像Count(*)、Sum(Price)或Avg(Quantity)那樣的單值，能夠使用ExecuteScalar方法。 ExecuteScalar返回第一行第一列的值，將結果集做爲標量值返回。由於單獨一步就能完成，因此ExecuteScalar不只簡化了代碼，還提高了性能。
　使用不返回行的SQL語句時，例如修改數據（INSERT、UPDATE或DELETE）或僅返回輸出參數或返回值，請使用ExecuteNonQuery。這避免了用於建立空DataReader的任何沒必要要處理。
　2.3.2 使用Prepare
　當須要重複執行同一SQL語句屢次，可考慮使用Prepare方法提高效率。須要注意的是，若是隻是執行一次或兩次，則徹底沒有必要。例如：
cmd.CommandText = "insert into Table1 ( Col1, Col2 ) values ( @val1, @val2 )";

cmd.Parameters.Add( "@val1", SqlDbType.Int, 4, "Col1" );
cms.Parameters.Add( "@val2", SqlDbType.NChar, 50, "Col2");

cmd.Parameters[0].Value = 1;
cmd.Parameters[1].Value = "XXX";
cmd.Prepare();
cmd.ExecuteNonQuery();

cmd.Parameters[0].Value = 2;
cmd.Parameters[1].Value = "YYY";
cmd.ExecuteNonQuery();

cmd.Parameters[0].Value = 3;
cmd.Parameters[1].Value = "ZZZ";
cmd.ExecuteNonQuery();

2.3.3 使用綁定變量 ★
　 SQL語句須要先被編譯成執行計劃，而後再執行。若是使用綁定變量的方式，那麼這個執行計劃就能夠被後續執行的SQL語句所複用。而若是直接把參數合併到了SQL語句中，因爲參數值變幻無窮，執行計劃就難以被複用了。例如上面Prepare一節給出的示例，若是把參數值直接寫到insert語句中，那麼上面的四次調用將須要編譯四次執行計劃。
　爲避免這種狀況形成性能損失，要求一概使用綁定變量方式。
　2.4 DataReader
　 DataReader最適合於訪問只讀的單向數據集。與DataSet不一樣，數據集並不所有在內存中，而是隨不斷髮出的read請求，一旦發現數據緩衝區中的數據均被讀取，則從數據源傳輸一個數據緩衝區大小的數據塊過來。另外，DataReader保持鏈接，DataSet則與鏈接斷開。
　2.4.1 顯式關閉DataReader
　與鏈接相似，也須要顯式關閉DataReader。另外，若是與DataReader關聯的Connection僅爲DataReader服務的話，可考慮使用Command對象的ExecuteReader(CommandBehavior.CloseConnection)方式。這能夠保證當 DataReader關閉時，同時自動關閉Connection。
　2.4.2 用索引號訪問代替名稱索引號訪問屬性
　從Row中訪問某列屬性，使用索引號的方式比使用名稱方式有細微提升。若是會被頻繁調用，例如在循環中，那麼可考慮此類優化。示例以下：
cmd.CommandText = "select Col1, Col2 from Table1" ;
SqlDataReader dr = cmd.ExecuteReader();

int col1 = dr.GetOrdinal("Col1");
int col2 = dr.GetOrdinal("Col2");

while (dr.Read())
{
Console.WriteLine( dr[col1] + "_" + dr[col2]);
}

2.4.3 使用類型化方法訪問屬性
　從Row中訪問某列屬性，用GetString、GetInt32這種顯式指明類型的方法，其效率較通用的GetValue方法有細微提升，由於不須要作類型轉換。
　2.4.4 使用多數據集
　部分場景能夠考慮一次返回多數據集來下降網絡交互次數，提高效率。示例以下：
cmd.CommandText = "StoredProcedureName"; // The stored procedure returns multiple result sets.
SqlDataReader dr = cmd.ExecuteReader();

while (dr.read())
// read first result set

dr.NextResult();

while (dr.read())
//

2.5 DataSet
　2.5.1 利用索引加快查找行的效率
　若是須要反覆查找行，建議增長索引。有兩種方式：
　1. 設置DataTable的PrimaryKey
　適用於按PrimaryKey查找行的狀況。注意此時應調用DataTable.Rows.Find方法，通常慣用的Select方法不能利用索引。
　2. 使用DataView
　適用於按Non-PrimaryKey查找行的狀況。可爲DataTable建立一個DataView，並經過SortOrder參數指示創建索引。此後使用Find或FindRows查找行。

3.1 減小往返行程（Reduce Round Trips）
　使用下面的方法能夠減小Web服務器和Browser之間的往返行程：
　1. 爲Browser啓用緩存
　若是呈現的內容是靜態的或變化週期較長，應啓用Browser緩存，避免發出冗餘的http請求。

2. 緩衝頁面輸出
　若是可能，則儘可能緩衝頁面輸出，處理結束後再一次傳送到客戶端，這能夠避免頻繁傳遞小塊內容所形成的屢次網絡交互。因爲這種方式在頁面處理結束以前客戶端沒法看到頁面內容，所以若是一個頁面的尺寸較大的話，可考慮使用 Response.Flush方法。該方法強制輸出迄今爲止在緩衝區中的內容，你應當採用合理的算法控制調用Response.Flush方法的次數。

3. 使用Server.Transfer重定向請求
　使用Server.Transfer方法重定向請求優於Response.Redirect方法。緣由是Response.Redirect會向Broswer回送一個響應頭，在響應頭中指出重定向的 URL，以後Brower使用新的URL從新發出請求。而Server.Transfer方法直接是一個簡單的服務端調用，徹底沒有這些開銷！
　須要注意Server.Transfer有侷限性：第一，它會跳過安全檢查；第二，只適用於在同一Web應用內的頁面間跳轉。

3.2 避免阻塞和長時間的做業
　若是須要運行阻塞或長時間運行的操做，能夠考慮使用異步調用的機制，以便Web服務器可以繼續處理其它的請求。
　1. 使用異步方式調用Web服務和遠程對象
　只要有可能就要避免在請求的處理過程當中對Web服務和遠程對象的同步調用，由於它佔用的是的ASP.NET 線程池中的工做線程，這將直接影響Web服務器響應其它請求的能力。

2. 考慮給不須要返回值的Web方法或遠程對象的方法添加OneWay屬性
　這種模式能讓Web Server調用以後就當即返回。可根據實際狀況決定是否使用這種方法。

3. 使用工做隊列
　將做業提交到服務器上的工做隊列中。客戶端經過發送請求來輪詢做業的執行結果。

3.3 使用緩存
　緩存能在很大程度上決定ASP.NET應用的最終性能。Asp.net支持頁面輸出緩存和頁面部分緩存，並提供Cache API，供應用程序緩存本身的數據。是否使用緩存可考慮下面的要點：
　　1. 識別建立與訪問代價較大的數據
　　2. 評估須要緩存數據的易變性
　　3. 評估數據的使用頻次
　　4. 將要緩存數據中易變數據和不變數據分離，只緩存不變數據
　　5. 選擇合適的緩存機制（除Asp.net Cache外，Application state和Session state也能夠做爲緩存使用）

3.4 多線程
　1. 避免在請求處理過程當中建立線程
　在執行請求的過程當中建立線程是一種代價較大的操做，會嚴重影響Web Server的性能。若是後續的操做必須用線程完成，建議經過thread pool來建立/管理線程。

2. 不要依賴線程數據槽或線程靜態變量
　因爲執行請求的線程是ASP.NET thread pool中的工做線程，同一個Client的兩次請求不必定由相同的線程來處理。

3. 避免阻塞處理請求的線程
　參考"避免阻塞和長時間的做業"小節。

4. 避免異步調用
　這和1的狀況相似。異步調用會致使建立新的線程，增長服務器的負擔。因此，若是沒有併發的做業要執行，就不要執行異步調用。

3.5 系統資源
　　1. 考慮實現資源池以提高性能
　　2. 明確地調用Dispose或Close釋放系統資源
　　3. 不要緩存或長時間佔用資源池中的資源
　　4. 儘量晚的申請，儘量早的釋放

3.6 頁面處理
　1. 儘可能減少Page的尺寸
　包括縮短控件的名稱、CSS的class的名稱、去掉無謂空行和空格、禁用不須要的ViewState
　2. 啓用頁面輸出的緩衝區（Buffer）
　若是Buffer的機制被關閉，能夠用下面的方法打開。
　使用程序打開頁面輸出緩存：
　Response.BufferOutput = true;

使用@Page開關打開頁面輸出緩衝機制：
　<%@ Page Buffer = "true" %>

使用Web.config或Machine.config配置文件的<pages>節點：
　<pages buffer="true" …>
　3. 利用Page.IsPostBack優化頁面輸出
　4. 經過分離頁面的不一樣的內容，來提升緩存效率和減小呈現的時間
　5. 優化複雜和代價較大的循環
　6. 合理利用客戶端的計算資源，將一些操做轉移到客戶端進行

3.7 ViewState
　ViewState是Asp.net爲服務端控件在頁面回傳之間跟蹤狀態信息而設計的一種機制。
　1. 關閉ViewState
　若是不須要跟蹤頁面狀態，例如頁面不會回傳（PostBack）、不須要處理服務端控件事件或者每次頁面刷新時都會從新計算控件內容，那麼就不須要用ViewState來記錄頁面狀態了。能夠對特定的WebControl設置EnableViewState屬性，也能夠在頁面一級設置：
　<%@ Page EnableViewState="false" %>

2. 在恰當的時間點初始化控件屬性
　ASP.NET的控件在執行構造函數、初始化的期間設置的屬性不會被跟蹤變化；而在初始化階段以後對屬性的修改都會被跟蹤，並最終記錄到IE頁面的__VIEWSTATE之中。因此，選擇合理的初始化控件屬性的執行點，能有效的減少頁面尺寸。

3. 謹慎選擇放到ViewState中的內容
　放到ViewState中的內容會被序列化/反序列化，Asp.net爲String、Integer、Boolean等基本類型的序列化作了優化，若是Array、ArrayList、 HashTable存儲的是基本類型效率也較高，但其它類型則須要提供類型轉換器（Type Converter），不然將使用代價昂貴的二進制序列化程序。

4.1 JScript性能優化的基本原則
　1. 儘量少地減小執行次數。畢竟對解釋語言來講，每個執行步驟，都須要和解釋引擎作一次交互。
　2. 儘量使用語言內置的功能，好比串連接。
　3. 儘量使用系統提供的API來進行優化。由於這些API是編譯好的二進制代碼，執行效率很高。
　4. 書寫最正確的代碼。容錯功能是要付出性能代價的。

javascript:
4.2 JScript語言自己的優化
　4.2.1 變量
　1. 儘可能使用局部變量。
　由於全局變量實際上是全局對象的成員，而局部變量在棧上定義，優先查找，性能相對於全局變量要高。

2. 儘可能在一個語句中作定義變量和賦值。

3. 省略沒必要要的變量定義。
　若是變量的定義能夠被一個常量替代，就直接使用常量。

4. 使用Object語法對對象賦值。
　Object的賦值語法在操做複雜對象時效率更高。
　例如，能夠將下面的代碼：
car = new Object();
car.make = "Honda";
car.model = "Civic";
car.transmission = "manual";
car.miles = 100000;
car.condition = "needs work";
替換成：

car = {
make: "Honda",
model: "Civic",
transmission: "manual",
miles: 100000,
condition: "needs work"
}

4.2.2 對象緩存
　1. 緩存對象查找的中間結果。
　由於JavaScript的解釋性，因此a.b.c.d.e，須要進行至少4次查詢操做，先檢查a再檢查a中的b，再檢查b中的c，如此往下。因此若是這樣的表達式重複出現，只要可能，應該儘可能少出現這樣的表達式，能夠利用局部變量，把它放入一個臨時的地方進行查詢。

2. 緩存建立時間較長的對象。
　自定義高級對象和Date、RegExp對象在構造時都會消耗大量時間。若是能夠複用，應採用緩存的方式。

4.2.3 字符串操做
　1. 使用"+=" 追加字符串，使用"+"來鏈接字符串。
　若是是追加字符串，最好使用s+=anotherStr操做，而不是要使用s=s+anotherStr。
　若是要鏈接多個字符串，應該使用"+"，如：
　　s+=a;
　　s+=b;
　　s+=c;
　　應該寫成
　　s+=a + b + c；

2. 鏈接大量的字符串，應使用Array的join方法。
　若是是收集字符串，最好使用JavaScript數組緩存，最後使用join方法鏈接起來，以下：
var buf = new Array();
for (var i = 0; i < 100; i++)
{
buf.push(i.toString());
}

var all = buf.join("");

4.2.4 類型轉換
　1. 使用Math.floor()或者Math.round()將浮點數轉換成整型。
　浮點數轉換成整型，這個更容易出錯，不少人喜歡使用parseInt()，其實parseInt()是用於將字符串轉換成數字，而不是浮點數和整型之間的轉換，咱們應該使用Math.floor()或者Math.round()。
　對象查找中的問題不同，Math是內部對象，因此Math.floor()其實並無多少查詢方法和調用的時間，速度是最快的。

2. 自定義的對象，推薦定義和使用toString()方法來進行類型轉換。
　對於自定義的對象，若是定義了toString()方法來進行類型轉換的話，推薦顯式調用toString()。由於內部的操做在嘗試全部可能性以後，會嘗試對象的toString()方法嘗試可否轉化爲String，因此直接調用這個方法效率會更高。

4.2.5 循環的優化
　1. 儘量少使用for(in)循環。
　在JavaScript中，咱們能夠使用for(;;),while(),for(in)三種循環，事實上，這三種循環中for(in)的效率極差，由於他須要查詢散列鍵，只要能夠就應該儘可能少用。

2. 預先計算collection的length。
　如：將for (var i = 0; i < collection.length; i++)
　替換成：for (var i = 0, len = collection.length; i < len; i++)
　效果會更好，尤爲是在大循環中。

3. 儘可能減小循環內的操做。
　循環內的每一個操做，都會被放大爲循環次數的倍數。因此，大循環內微小的改進，在性能的總體提高上都是可觀的。

4. 使用循環替代遞歸。
　相比循環，遞歸的效率更差一些。遞歸的優勢是在形式上更天然一些。因此，在不影響代碼的維護性的前提下，用循環替代遞歸。

4.2.6 其它方面
　1. 儘可能使用語言內置的語法。
　 "var arr = […];"和"var arr = new Array(…);"是等效的，可是前者的效能優於後者。一樣，"var foo = {};"的方式也比"var foo = new Object();"快；"var reg = /../;"要比"var reg=new RegExp()"快。

2. 儘可能不要使用eval。
　使用eval，至關於在運行時再次調用解釋引擎，對傳入的內容解釋運行，須要消耗大量時間。

3. 使用prototype代替closure。
　使用closure在性能和內存消耗上都是不利的。若是closure使用量過大，這就會成爲一個問題。因此，儘可能將：
　this.methodFoo = function()
　替換成：
　MyClass.protoype.methodFoo = function()
　和closure存在於對象實例之中不一樣，prototype存在於類中，被該類的全部的對象實例共享。

4. 避免使用with語句。
　With語句臨時擴展對象查找的範圍，節省了文字的錄入時間，但付出了更多的執行時間。由於每一個給出的名稱都要在全局範圍查找。因此，能夠將下面的代碼：
with (document.formname)
{
field1.value = "one";
field2.value = "two";
}
變動爲：

var form = document.formname;
form.field1.value = "one";
form.field2.value = "two";

4.3 DOM相關
　4.3.1 建立DOM節點
　相比較經過document.write來給頁面生成內容，找一個容器元素（好比指定一個div或者span）並設置他們的innerHTML效率更高。
　而設置innerHTML的方式比經過createElement方法建立節點的效率更高。事實上，設置元素的innerHTML是建立節點效率最高的一種方式。
　若是必須使用createElement方法，而若是文檔中存在現成的樣板節點，應該是用cloneNode()方法。由於使用 createElement()方法以後，你須要設置屢次元素的屬性，使用cloneNode()則能夠減小屬性的設置次數。一樣，若是須要建立不少元素，應該先準備一個樣板節點。

4.3.2 離線操做大型的DOM樹
　在添加一個複雜的DOM樹時，能夠先構造，構造結束後再將其添加到DOM數的適當節點。這可以節省界面刷新的時間。

一樣，在準備編輯一個複雜的樹時，能夠先將樹從DOM樹上刪除，等編輯結束後再添加回來。

　4.3.3 對象查詢
　使用[""]查詢要比.item()更快。調用.item()增長了一次查詢和函數的調用。

4.3.4 定時器
　若是針對的是不斷運行的代碼，不該該使用setTimeout，而應該用setInterval。setTimeout每次要從新設置一個定時器。

4.4 其餘　1. 儘可能減少文件尺寸。　將JScript文件中無關的空行、空格、註釋去掉，有助於減少JS文件的尺寸，提升下載的時間。（能夠經過工具來支持代碼發佈）　2. 儘可能不要在同一個Page內同時引用JScript和VBScript引擎　3. 將Page內的JScript移入到單獨的JS文件中。　4. 將Page內的JScript放置在Page的最下面，有助於提升頁面的響應速度。　5. 利用cache，減小JScript文件的下載次數　6. 在HTML內書寫JScript文件的URL時，注意統一大小寫。這樣能夠利用前面URL緩存的文件。　7. 推薦使用JScript Lint檢查Javascript代碼。畢竟源碼天空，對JScript引擎來講，最容易理解的JScript代碼，執行的效率也就最高。