ASP.NET:

一、返回多個數(shù)據(jù)集

　　檢查你的訪問數(shù)據(jù)庫的代碼，看是否存在著要返回多次的請求。每次往返降低了你的應(yīng)用程序的每秒能夠響應(yīng)請求的次數(shù)。通過在單個數(shù)據(jù)庫請求中返回多個結(jié)果集，可以減少與數(shù)據(jù)庫通信的時間，使你的系統(tǒng)具有擴展性，也可以減少數(shù)據(jù)庫服務(wù)器響應(yīng)請求的工作量。

　　如果用動態(tài)的SQL語句來返回多個數(shù)據(jù)集，那用存儲過程來替代動態(tài)的SQL語句會更好些。是否把業(yè)務(wù)邏輯寫到存儲過程中，這個有點爭議。但是我認為，把業(yè)務(wù)邏輯寫到存儲過程里面可以限制返回結(jié)果集的大小，減小網(wǎng)絡(luò)數(shù)據(jù)的流量，在邏輯層也不用在過濾數(shù)據(jù)，這是一個好事情。

　　用SqlCommand對象的ExecuteReader方法返回一個強類型的業(yè)務(wù)對象，再調(diào)用NextResult方法來移動數(shù)據(jù)集指針來定位數(shù)據(jù)集。返回多個ArrayList強類型對象。只從數(shù)據(jù)庫中返回你需要的數(shù)據(jù)可以大大的減小你的服務(wù)器所耗用的內(nèi)存。

二、對數(shù)據(jù)進行分頁

　　ASP.NET的DataGrid有一個非常有用的功能：分頁。如果DataGrid允許分頁，在某一時刻它只下載某一頁的數(shù)據(jù)，另外，它有一個數(shù)據(jù)分頁的濟覽導航欄，它讓你可以選擇瀏覽某一頁，而且每次只下載一頁的數(shù)據(jù)。

　　但是它有一個小小的缺點，就是你必須把所有的數(shù)據(jù)都綁定到DataGrid中。也就是說，你的數(shù)據(jù)層必須返回所有的數(shù)據(jù)，然后DataGrid再根據(jù)當前頁過濾出當前頁所需要的數(shù)據(jù)顯示出來。如果有一個一萬條記錄的結(jié)果集要用DataGrid進行分頁，假設(shè)DataGrid每頁只顯示25條數(shù)據(jù)，那就意味著每次請求都有9975條數(shù)據(jù)都是要丟棄的。每次請求都要返回這么大的數(shù)據(jù)集，對應(yīng)用程序的性能影響是非常大的。

　　一個好的解決方案是寫一個分頁的存儲過程，例如對Northwind數(shù)據(jù)庫orders表的分頁存儲過程。你只需要傳當前頁碼，每頁顯示的條數(shù)兩個參數(shù)進來，存儲過程會返回相應(yīng)的結(jié)果。

　　在服務(wù)器端，專門寫了一個分頁的控件來處理數(shù)據(jù)的分頁，在一個存儲過程里面返回了兩個結(jié)果集：數(shù)據(jù)記錄總數(shù)和要求的結(jié)果集。

　　返回的記錄總數(shù)取決于要執(zhí)行查詢，例如，一個where條件可以限制返回的結(jié)果集的大小。因為在分頁界面中必須要根據(jù)數(shù)據(jù)集記錄的大小來計算總的頁數(shù)，所以必須要返回結(jié)果集的記錄數(shù)。例如，如果一共有1000000條記錄，如果用where條件就可以過濾成只返回1000條記錄，存儲過程的分頁邏輯應(yīng)該知道返回那些需要顯示的數(shù)據(jù)。

三、連接池

　　用TCP來連接你的應(yīng)用程序與數(shù)據(jù)庫是一件昂貴的事情（很費時的事情），微軟的開發(fā)者可以通過用連接池來反復(fù)的使用數(shù)據(jù)庫的連接。比起每次請求都用TCP來連一次數(shù)據(jù)庫，連接池只有在不存在有效的連接時才新建一個TCP 連接。當關(guān)閉一個連接的時候，它會被放到池中，它仍然會保持與數(shù)據(jù)庫的連接，這樣就可以減少與數(shù)據(jù)庫的TCP連接次數(shù)。

　　當然，你要注意那些忘記關(guān)的連接，你應(yīng)在每次用完連接后馬上關(guān)閉它。要強調(diào)的是：無論什么人說.net framework中的GC(垃圾收集器)總會在你用完連接對象后調(diào)用連接對象的Close或者Dispose方法顯式的關(guān)閉你的連接。不要期望CLR會在你想象的時間內(nèi)關(guān)掉連接，雖然CLR最終都要銷毀對象和關(guān)閉邊接，但是我們并不能確定它到底會在什么時候做這些事情。

　　要用連接池優(yōu)化，有兩條規(guī)則，第一，打開連接，處理數(shù)據(jù)，然后關(guān)閉連接。如果你必須在每次請求中多次打開或關(guān)閉連接，這好過一直打開一個邊接，然后把它傳到各個方法中。第二，用相同的連接字符串（或者用相同的用戶標識，當你用集成認證的時候）。如果你沒有用相同的連接字符串，如你用基于登錄用戶的連接字符串，這將不能利用連接池的優(yōu)化功能。如果你用的是集成的論證，因為用戶很多，所以你也不能充分利用連接池的優(yōu)化功能。.NET CLR提供了一個數(shù)據(jù)性能計數(shù)器，它在我們需要跟蹤程序性能特性的時候非常有用，當然也包括連接池的跟蹤了。

　　無論你的應(yīng)用程序什么時候要連在另一臺機子的資源，如數(shù)據(jù)庫，你都應(yīng)該重點優(yōu)化你連資源所花的時間，接收和發(fā)送數(shù)據(jù)的時間，以及往返回之間的次數(shù)。優(yōu)化你的應(yīng)用程序中的每一個處理點（process hop），它是提高你的應(yīng)用的性能的出發(fā)點。

　　應(yīng)用程序?qū)影c數(shù)據(jù)層連接，傳送數(shù)據(jù)到相應(yīng)的類的實例以及業(yè)務(wù)處理的邏輯。例如，在Community Server中，要組裝一個Forums或者Threads集合，然后應(yīng)用業(yè)務(wù)邏輯，如授權(quán)，更重要的，這里要完成緩存邏輯。

四、ASP.NET緩存API

　　在寫應(yīng)用程序之前,你要做的第一件事是讓應(yīng)用程序最大化的利用ASP.NET的緩存功能。

　　如果你的組件是要在Asp.net應(yīng)用程序中運行，你只要把System.Web.dll引用到你的項目中就可以了。然后用 HttpRuntime.Cache屬性就可訪問Cache了（也可以通過Page.Cache或HttpContext.Cache訪問）。

　　有以下幾條緩存數(shù)據(jù)的規(guī)則。第一，數(shù)據(jù)可能會被頻繁的被使用，這種數(shù)據(jù)可以緩存。第二，數(shù)據(jù)的訪問頻率非常高，或者一個數(shù)據(jù)的訪問頻率不高，但是它的生存周期很長，這樣的數(shù)據(jù)最好也緩存起來。第三是一個常常被忽略的問題，有時候我們緩存了太多數(shù)據(jù)，通常在一臺X86的機子上，如果你要緩存的數(shù)據(jù)超過 800M的話，就會出現(xiàn)內(nèi)存溢出的錯誤。所以說緩存是有限的。換名話說，你應(yīng)該估計緩存集的大小，把緩存集的大小限制在10以內(nèi)，否則它可能會出問題。在 Asp.net中，如果緩存過大的話也會報內(nèi)存溢出錯誤，特別是如果緩存大的DataSet對象的時候。

這里有幾個你必須了解的重要的緩存機制。首先是緩存實現(xiàn)了“最近使用”原則（ a least-recently-used algorithm），當緩存少的時候，它會自動的強制清除那些無用的緩存。其次 “條件依賴”強制清除原則（expiration dependencies），條件可以是時間，關(guān)鍵字和文件。以時間作為條件是最常用的。在asp.net2.0中增加一更強的條件，就是數(shù)據(jù)庫條件。當數(shù)據(jù)庫中的數(shù)據(jù)發(fā)生變化時，就會強制清除緩存　　

五、預(yù)請求緩存

　　在前面，我們只對某些地方作了一個小小的性能改進也可以獲得大的性能提升，用預(yù)請求緩存來提升程序的性能是很不錯的。

　　雖然Cache API設(shè)計成用來保存某段時間的數(shù)據(jù)，而預(yù)請求緩存只是保存某個時期的某個請求的內(nèi)容。如果某個請求的訪問頻率高，而且這個請求只需要提取，應(yīng)用，修改或者更新數(shù)據(jù)一次。那么就可以預(yù)緩存該請求。我們舉個例子來說明。

　　在BS的論壇應(yīng)用程序中，每一個頁面的服務(wù)器控件都要求得到用于決定它的皮膚（skin）的自定義的數(shù)據(jù)，以決定用哪個樣式表及其它的一些個性化的東西。這里面的某些數(shù)據(jù)可能要長時間的保存，有些時間則不然，如控件的skin數(shù)據(jù)，它只需要應(yīng)用一次，而后就可以一直使用。

　　要實現(xiàn)預(yù)請求緩存，用Asp.net 的HttpContext類，HttpContext類的實例在每一個請求中創(chuàng)建，在請求期間的任何地方都可以通過 HttpContext.Current屬性訪問。HttpContext類有一個Items集合屬性，在請求期間所有的對象和數(shù)據(jù)都被添加到這個集合中緩存起來。和你用Cache緩存訪問頻率高數(shù)據(jù)一樣，你可以用HttpContext.Items緩存那些每個請求都要用到的基礎(chǔ)數(shù)據(jù)。它背后的邏輯很簡單：我們向HttpContext.Items中添加一個數(shù)據(jù)，然后再從它里面讀出數(shù)據(jù)。

六、后臺處理

　　通過上面的方法你的應(yīng)用程序應(yīng)該運行得很快了，是不是？但是在某些時候，程序中的一次請求中可能要執(zhí)行一個非常耗時的任務(wù)。如發(fā)送郵件或者是檢查提交的數(shù)據(jù)的正確性等。

　　當我們把asp.net Forums 1.0集成在CS中的時侯，發(fā)現(xiàn)提交一個新的帖子的時候會非常的慢。每次新增一個帖子的時侯，應(yīng)用程序首先要檢查這個帖子是不是重復(fù)提的，然后用 “badword”過濾器來過濾，檢查圖片附加碼，作帖子的索引，把它添加到合適的隊列中，驗證它的附件，最后，發(fā)郵件到它的訂閱者郵件箱中。顯然，這個工作量很大。

　　結(jié)果是它把大量的時間都花在做索引和發(fā)送郵件中了。做帖子的索引是一項很耗時的操作，而發(fā)郵件給訂閱都需要連接到SMTP服務(wù)，然后給每一個訂閱者都發(fā)一封郵件，隨著訂閱用戶的增加，發(fā)送郵件的時間會更長。

　　索引和發(fā)郵件并不需要在每次請求時觸發(fā)，理想狀態(tài)下，我們想要批量的處理這些操作，每次只發(fā)25封郵件或者每隔5分鐘把所有的要發(fā)的新郵件發(fā)一次。我們決定使用與數(shù)據(jù)庫原型緩存一樣的代碼，但是失敗了，所以又不得不回到VS.NET 2005。

　　我們在System.Threading命名空間下找到了Timer類，這個類非常有用，但卻很少有人知道，Web開發(fā)人員則更少有人知道了。一旦他建了該類的實例，每隔一個指定的時間，Timer類就會從線程池中的一個線程中調(diào)用指定的回調(diào)函數(shù)。這意味著你的asp.net應(yīng)用程序可以在沒有請求的時候也可以運行。這就是后以處理的解決方案。你就可以讓做索引和發(fā)郵件工作在后臺運行，而不是在每次請求的時候必須執(zhí)行。

　　后臺運行的技術(shù)有兩個問題，第一是，當你的應(yīng)用程序域卸載后，Timer類實例就會停止運行了。也就是不會調(diào)用回調(diào)方法了。另外，因為CLR的每個進程中都有許多的線程在運行，你將很難讓Timer獲得一個線程來執(zhí)行它，或者能執(zhí)行它，但會延時。Asp.net層要盡量少的使用這種技術(shù)，以減少進程中線程的數(shù)量，或者只讓請求用一小部分的線程。當然如果你有大量的異步工作的話，那就只能用它了。

七、頁面輸出緩存和代理服務(wù)

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

只要簡單的把下面的這一行代碼復(fù)制到你的頁面中就可以實現(xiàn)了：

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

就可以有效的利用第一次請求里生成的頁面輸出緩存內(nèi)容，60秒后重新生成一道頁面內(nèi)容。這種技術(shù)其實也是運用一些低層的Cache API來實現(xiàn)。用頁面輸出緩存有幾個參數(shù)可以配置，如上面所說的VaryByParams參數(shù)，該參數(shù)表示什么時候觸發(fā)重輸出的條件，也可以指定在 Http Get或Http Post 請求模式下緩存輸出。例如當我們設(shè)置該參數(shù)為VaryByParams=”Report”的時候，default.aspx?Report=1或者 default.aspx?Report=2請求的輸出都會被緩存起來。參數(shù)的值可以是多個用分號隔開參數(shù)。

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

　　雖然用頁面輸出緩存不提高你的應(yīng)用程序性能，但是它能減少了從的服務(wù)器中加載已緩存頁面內(nèi)容的次數(shù)。當然，這僅限于緩存匿名用戶可以訪問的頁面。因為一旦頁面被緩存后，就不能再執(zhí)行授權(quán)操作了。

八、 用IIS6.0的Kernel Caching

　　如果你的應(yīng)用程序沒用運行在IIS6.0(windows server 2003)中，那么你就失去了一些很好的提高應(yīng)用程序性能的方法。在第七個方法中，我講了用頁面輸出緩存提高應(yīng)用程序的性能的方法。在IIS5.0中，當一個請求到來到IIS后，IIS會把它轉(zhuǎn)給asp.net，當應(yīng)用了頁面輸出緩存時，ASP.NET中的HttpHandler會接到該請求，HttpHandler從緩存中把內(nèi)容取出來并返回。

　　如果你用的是IIS6.0，它有一個非常好的功能就是Kernel Caching，而且你不必修改asp.net程序中任何代碼。當asp.net接到一個已緩存的請求，IIS的Kernel Cache會從緩存中得到它的一份拷貝。當從網(wǎng)絡(luò)中傳來一個請求的時，Kernel層會得到該請求，如果該請求被緩存起來了，就直接把緩存的數(shù)據(jù)返回，這樣就完工了。這就意味著當你用IIS的Kernel Caching來緩存頁面輸出時，你將獲得不可置信的性能提升。在開發(fā)VS.NET 2005的 asp.net時有一點，我是專門負asp.net性能的程序經(jīng)理，我的程序員用了這個方法，我看了所有日報表數(shù)據(jù)，發(fā)現(xiàn)用kernel model caching的結(jié)果總是最快的。它們的一個共同的特征就是網(wǎng)絡(luò)的請求和響應(yīng)量很大,但IIS只占用了5%的CPU資源。這是令人驚奇的。有許多讓你使用用IIS6.0的理由，但kernel cashing是最好的一個。

九、 用Gzip壓縮數(shù)據(jù)

　　除非你的CPU占用率太高了，才有必要用提升服務(wù)器性能的技巧。用gzip壓縮數(shù)據(jù)的方法可以減少你發(fā)送到服務(wù)端的數(shù)據(jù)量，也可以提高頁面的運行速度，同時也減少了網(wǎng)絡(luò)的流量。怎么樣更好的壓縮數(shù)據(jù)取決于你要發(fā)送的數(shù)據(jù)，還有就是客戶端的瀏覽器支不支持（IIS把用gzip壓縮后的數(shù)據(jù)發(fā)送到客戶端，客戶端要支持gzip 才能解析，IE6.0和Firefox都支持）。這樣你的服務(wù)器每秒能多響應(yīng)一些請求，同樣，你也減少了發(fā)送響應(yīng)的數(shù)據(jù)量，也就能多發(fā)送一些請求了。

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

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

十、 服務(wù)器控件的ViewState

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

　　用ViewState會帶來一些負面的影響。首先，它加大的服務(wù)器的響應(yīng)和請求的時間。其次，每次回傳時都增加了序列化和反序列化數(shù)據(jù)的時間。最后，它還消耗了服務(wù)器更多的內(nèi)存。

　　許多的服務(wù)器控件很趨于使用ViewState，如DataGrid，而有時候是沒有必須使用的。默認情況下是允許使用ViewState的，如果你不想使用ViewState的話，你可以在控件或頁面級別把關(guān)閉它。在控件中，你只要把EnableViewState屬性設(shè)為False就可以了；你也可以在頁面中設(shè)置，使它的范圍擴展到整個頁面中： <%@ Page EnableViewState=”false” %> 如果頁面無需回傳或者每次請求頁面只是呈現(xiàn)控件。你就應(yīng)該在頁面級別中把ViewState關(guān)掉。



1. C#語言方面

1.1 垃圾回收
　垃圾回收解放了手工管理對象的工作，提高了程序的健壯性，但副作用就是程序代碼可能對于對象創(chuàng)建變得隨意。
　1.1.1 避免不必要的對象創(chuàng)建
　由于垃圾回收的代價較高，所以C#程序開發(fā)要遵循的一個基本原則就是避免不必要的對象創(chuàng)建。以下列舉一些常見的情形。
　1.1.1.1 避免循環(huán)創(chuàng)建對象 ★
　如果對象并不會隨每次循環(huán)而改變狀態(tài)，那么在循環(huán)中反復(fù)創(chuàng)建對象將帶來性能損耗。高效的做法是將對象提到循環(huán)外面創(chuàng)建。
　1.1.1.2 在需要邏輯分支中創(chuàng)建對象
　如果對象只在某些邏輯分支中才被用到，那么應(yīng)只在該邏輯分支中創(chuàng)建對象。
　1.1.1.3 使用常量避免創(chuàng)建對象
　程序中不應(yīng)出現(xiàn)如 new Decimal(0) 之類的代碼，這會導致小對象頻繁創(chuàng)建及回收，正確的做法是使用Decimal.Zero常量。我們有設(shè)計自己的類時，也可以學習這個設(shè)計手法，應(yīng)用到類似的場景中。
　1.1.1.4 使用StringBuilder做字符串連接

1.1.2 不要使用空析構(gòu)函數(shù) ★
　如果類包含析構(gòu)函數(shù)，由創(chuàng)建對象時會在 Finalize 隊列中添加對象的引用，以保證當對象無法可達時，仍然可以調(diào)用到 Finalize 方法。垃圾回收器在運行期間，會啟動一個低優(yōu)先級的線程處理該隊列。相比之下，沒有析構(gòu)函數(shù)的對象就沒有這些消耗。如果析構(gòu)函數(shù)為空，這個消耗就毫無意 義，只會導致性能降低！因此，不要使用空的析構(gòu)函數(shù)。
　在實際情況中，許多曾在析構(gòu)函數(shù)中包含處理代碼，但后來因為種種原因被注釋掉或者刪除掉了，只留下一個空殼，此時應(yīng)注意把析構(gòu)函數(shù)本身注釋掉或刪除掉。
　1.1.3 實現(xiàn) IDisposable 接口
　垃圾回收事實上只支持托管內(nèi)在的回收，對于其他的非托管資源，例如 Window GDI 句柄或數(shù)據(jù)庫連接，在析構(gòu)函數(shù)中釋放這些資源有很大問題。原因是垃圾回收依賴于內(nèi)在緊張的情況，雖然數(shù)據(jù)庫連接可能已瀕臨耗盡，但如果內(nèi)存還很充足的話，垃圾回收是不會運行的。
　 C#的 IDisposable 接口是一種顯式釋放資源的機制。通過提供 using 語句，還簡化了使用方式（編譯器自動生成 try ... finally 塊，并在 finally 塊中調(diào)用 Dispose 方法）。對于申請非托管資源對象，應(yīng)為其實現(xiàn) IDisposable 接口，以保證資源一旦超出 using 語句范圍，即得到及時釋放。這對于構(gòu)造健壯且性能優(yōu)良的程序非常有意義！
為防止對象的 Dispose 方法不被調(diào)用的情況發(fā)生，一般還要提供析構(gòu)函數(shù)，兩者調(diào)用一個處理資源釋放的公共方法。同時，Dispose 方法應(yīng)調(diào)用 System.GC.SuppressFinalize(this)，告訴垃圾回收器無需再處理 Finalize 方法了。

1.2 String 操作
　1.2.1 使用 StringBuilder 做字符串連接
　 String 是不變類，使用 + 操作連接字符串將會導致創(chuàng)建一個新的字符串。如果字符串連接次數(shù)不是固定的，例如在一個循環(huán)中，則應(yīng)該使用 StringBuilder 類來做字符串連接工作。因為 StringBuilder 內(nèi)部有一個 StringBuffer ，連接操作不會每次分配新的字符串空間。只有當連接后的字符串超出 Buffer 大小時，才會申請新的 Buffer 空間。典型代碼如下：StringBuilder sb = new StringBuilder( 256 );
for ( int i = 0 ; i < Results.Count; i ++ )
{
sb.Append (Results[i]);
}


如果連接次數(shù)是固定的并且只有幾次，此時應(yīng)該直接用 + 號連接，保持程序簡潔易讀。實際上，編譯器已經(jīng)做了優(yōu)化，會依據(jù)加號次數(shù)調(diào)用不同參數(shù)個數(shù)的 String.Concat 方法。例如：String str = str1 + str2 + str3 + str4;
　會被編譯為 String.Concat(str1, str2, str3, str4)。該方法內(nèi)部會計算總的 String 長度，僅分配一次，并不會如通常想象的那樣分配三次。作為一個經(jīng)驗值，當字符串連接操作達到 10 次以上時，則應(yīng)該使用 StringBuilder。

　 這里有一個細節(jié)應(yīng)注意：StringBuilder 內(nèi)部 Buffer 的缺省值為 16 ，這個值實在太小。按 StringBuilder 的使用場景，Buffer 肯定得重新分配。經(jīng)驗值一般用 256 作為 Buffer 的初值。當然，如果能計算出最終生成字符串長度的話，則應(yīng)該按這個值來設(shè)定 Buffer 的初值。使用 new StringBuilder(256) 就將 Buffer 的初始長度設(shè)為了256。
　1.2.2 避免不必要的調(diào)用 ToUpper 或 ToLower 方法
　String是不變類，調(diào)用ToUpper或ToLower方法都會導致創(chuàng)建一個新的字符串。如果被頻繁調(diào)用，將導致頻繁創(chuàng)建字符串對象。這違背了前面講到的“避免頻繁創(chuàng)建對象”這一基本原則。
　例如，bool.Parse方法本身已經(jīng)是忽略大小寫的，調(diào)用時不要調(diào)用ToLower方法。
　另一個非常普遍的場景是字符串比較。高效的做法是使用 Compare 方法，這個方法可以做大小寫忽略的比較，并且不會創(chuàng)建新字符串。
　 還有一種情況是使用 HashTable 的時候，有時候無法保證傳遞 key 的大小寫是否符合預(yù)期，往往會把 key 強制轉(zhuǎn)換到大寫或小寫方法。實際上 HashTable 有不同的構(gòu)造形式，完全支持采用忽略大小寫的 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），相同常量不會重復(fù)分配。

1.3 多線程

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


通常情況下，應(yīng)減小同步的范圍，使系統(tǒng)獲得更好的性能。簡單將整個方法標記為同步不是一個好主意，除非能確定方法中的每個代碼都需要受同步保護。
　1.3.1.2 同步策略
　使用 lock 進行同步，同步對象可以選擇 Type、this 或為同步目的專門構(gòu)造的成員變量。
　避免鎖定Type★
　 鎖定Type對象會影響同一進程中所有AppDomain該類型的所有實例，這不僅可能導致嚴重的性能問題，還可能導致一些無法預(yù)期的行為。這是一個很不 好的習慣。即便對于一個只包含static方法的類型，也應(yīng)額外構(gòu)造一個static的成員變量，讓此成員變量作為鎖定對象。
　避免鎖定 this
　 鎖定 this 會影響該實例的所有方法。假設(shè)對象 obj 有 A 和 B 兩個方法，其中 A 方法使用 lock(this) 對方法中的某段代碼設(shè)置同步保護?，F(xiàn)在，因為某種原因，B 方法也開始使用 lock(this) 來設(shè)置同步保護了，并且可能為了完全不同的目的。這樣，A 方法就被干擾了，其行為可能無法預(yù)知。所以，作為一種良好的習慣，建議避免使用 lock(this) 這種方式。
　使用為同步目的專門構(gòu)造的成員變量
　這是推薦的做法。方式就是 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);


調(diào)用 Synchronized 方法會返回一個可保證所有操作都是線程安全的相同集合對象?？紤] mySyncdAL[0] = mySyncdAL[0] + "test" 這一語句，讀和寫一共要用到兩個鎖。一般講，效率不高。推薦使用 SyncRoot 屬性，可以做比較精細的控制。

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


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


創(chuàng)建單例對象是很常見的一種編程情況。一般在 lock 語句后就會直接創(chuàng)建對象了，但這不夠安全。因為在 lock 鎖定對象之前，可能已經(jīng)有多個線程進入到了第一個 if 語句中。如果不加第二個 if 語句，則單例對象會被重復(fù)創(chuàng)建，新的實例替代掉舊的實例。如果單例對象中已有數(shù)據(jù)不允許被破壞或者別的什么原因，則應(yīng)考慮使用 Double Check 技術(shù)。

1.4 類型系統(tǒng)
　1.4.1 避免無意義的變量初始化動作
　CLR保證所有對象在訪問前已初始化，其做法是將分配的內(nèi)存清零。因此，不需要將變量重新初始化為0、false或null。
　需要注意的是：方法中的局部變量不是從堆而是從棧上分配，所以C#不會做清零工作。如果使用了未賦值的局部變量，編譯期間即會報警。不要因為有這個印象而對所有類的成員變量也做賦值動作，兩者的機理完全不同！
　1.4.2 ValueType 和 ReferenceType

1.4.2.1 以引用方式傳遞值類型參數(shù)
　值類型從調(diào)用棧分配，引用類型從托管堆分配。當值類型用作方法參數(shù)時，默認會進行參數(shù)值復(fù)制，這抵消了值類型分配效率上的優(yōu)勢。作為一項基本技巧，以引用方式傳遞值類型參數(shù)可以提高性能。
　1.4.2.2 為 ValueType 提供 Equals 方法
　 .net 默認實現(xiàn)的 ValueType.Equals 方法使用了反射技術(shù)，依靠反射來獲得所有成員變量值做比較，這個效率極低。如果我們編寫的值對象其 Equals 方法要被用到（例如將值對象放到 HashTable 中），那么就應(yīng)該重載 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#可以在值類型和引用類型之間自動轉(zhuǎn)換，方法是裝箱和拆箱。裝箱需要從堆上分配對象并拷貝值，有一定性能消耗。如果這一過程發(fā)生在循環(huán)中或是作為底層方法被頻繁調(diào)用，則應(yīng)該警惕累計的效應(yīng)。
　一種經(jīng)常的情形出現(xiàn)在使用集合類型時。例如：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 異常處理
　異常也是現(xiàn)代語言的典型特征。與傳統(tǒng)檢查錯誤碼的方式相比，異常是強制性的（不依賴于是否忘記了編寫檢查錯誤碼的代碼）、強類型的、并帶有豐富的異常信息（例如調(diào)用棧）。
　1.5.1 不要吃掉異?！?
　關(guān)于異常處理的最重要原則就是：不要吃掉異常。這個問題與性能無關(guān)，但對于編寫健壯和易于排錯的程序非常重要。這個原則換一種說法，就是不要捕獲那些你不能處理的異常。
　吃掉異常是極不好的習慣，因為你消除了解決問題的線索。一旦出現(xiàn)錯誤，定位問題將非常困難。除了這種完全吃掉異常的方式外，只將異常信息寫入日志文件但并不做更多處理的做法也同樣不妥。
　1.5.2 不要吃掉異常信息★
　有些代碼雖然拋出了異常，但卻把異常信息吃掉了。
　為異常披露詳盡的信息是程序員的職責所在。如果不能在保留原始異常信息含義的前提下附加更豐富和更人性化的內(nèi)容，那么讓原始的異常信息直接展示也要強得多。千萬不要吃掉異常。
　1.5.3 避免不必要的拋出異常
　拋出異常和捕獲異常屬于消耗比較大的操作，在可能的情況下，應(yīng)通過完善程序邏輯避免拋出不必要不必要的異常。與此相關(guān)的一個傾向是利用異常來控制處理邏輯。盡管對于極少數(shù)的情況，這可能獲得更為優(yōu)雅的解決方案，但通常而言應(yīng)該避免。
　1.5.4 避免不必要的重新拋出異常
　如果是為了包裝異常的目的（即加入更多信息后包裝成新異常），那么是合理的。但是有不少代碼，捕獲異常沒有做任何處理就再次拋出，這將無謂地增加一次捕獲異常和拋出異常的消耗，對性能有傷害。

1.6 反射
　反射是一項很基礎(chǔ)的技術(shù)，它將編譯期間的靜態(tài)綁定轉(zhuǎn)換為延遲到運行期間的動態(tài)綁定。在很多場景下（特別是類框架的設(shè)計），可以獲得靈活易于擴展的架構(gòu)。但帶來的問題是與靜態(tài)綁定相比，動態(tài)綁定會對性能造成較大的傷害。
　1.6.1 反射分類
　 type comparison ：類型判斷，主要包括 is 和 typeof 兩個操作符及對象實例上的 GetType 調(diào)用。這是最輕型的消耗，可以無需考慮優(yōu)化問題。注意 typeof 運算符比對象實例上的 GetType 方法要快，只要可能則優(yōu)先使用 typeof 運算符。
　member enumeration ： 成員枚舉，用于訪問反射相關(guān)的元數(shù)據(jù)信息，例如Assembly.GetModule、Module.GetType、Type對象上的 IsInterface、IsPublic、GetMethod、GetMethods、GetProperty、GetProperties、 GetConstructor調(diào)用等。盡管元數(shù)據(jù)都會被CLR緩存，但部分方法的調(diào)用消耗仍非常大，不過這類方法調(diào)用頻度不會很高，所以總體看性能損失程 度中等。
　member invocation：成員調(diào)用，包括動態(tài)創(chuàng)建對象及動態(tài)調(diào)用對象方法，主要有Activator.CreateInstance、Type.InvokeMember等。
　1.6.2 動態(tài)創(chuàng)建對象
　C#主要支持 5 種動態(tài)創(chuàng)建對象的方式：
　　1. Type.InvokeMember
　　2. ContructorInfo.Invoke
　　3. Activator.CreateInstance(Type)
　　4. Activator.CreateInstance(assemblyName, typeName)
　　5. Assembly.CreateInstance(typeName)
　最快的是方式 3 ，與 Direct Create 的差異在一個數(shù)量級之內(nèi)，約慢 7 倍的水平。其他方式，至少在 40 倍以上，最慢的是方式 4 ，要慢三個數(shù)量級。
　1.6.3 動態(tài)方法調(diào)用
　 方法調(diào)用分為編譯期的早期綁定和運行期的動態(tài)綁定兩種，稱為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）技術(shù)生成IL代碼來實現(xiàn)動態(tài)調(diào)用。
　從測試結(jié)果看，相比Direct Call，Type.InvokeMember要接近慢三個數(shù)量級；MethodBase.Invoke雖然比Type.InvokeMember要快三 倍，但比Direct Call仍慢270倍左右?？梢妱討B(tài)方法調(diào)用的性能是非常低下的。我們的建議是：除非要滿足特定的需求，否則不要使用！
　1.6.4 推薦的使用原則
　模式
　　1． 如果可能，則避免使用反射和動態(tài)綁定
　　2． 使用接口調(diào)用方式將動態(tài)綁定改造為早期綁定
　　3． 使用Activator.CreateInstance(Type)方式動態(tài)創(chuàng)建對象
　　4． 使用typeof操作符代替GetType調(diào)用
　反模式
　　1． 在已獲得Type的情況下，卻使用Assembly.CreateInstance(type.FullName)

1.7 基本代碼技巧
　這里描述一些應(yīng)用場景下，可以提高性能的基本代碼技巧。對處于關(guān)鍵路徑的代碼，進行這類的優(yōu)化還是很有意義的。普通代碼可以不做要求，但養(yǎng)成一種好的習慣也是有意義的。
　1.7.1 循環(huán)寫法
　 可以把循環(huán)的判斷條件用局部變量記錄下來。局部變量往往被編譯器優(yōu)化為直接使用寄存器，相對于普通從堆或棧中分配的變量速度快。如果訪問的是復(fù)雜計算屬性 的話，提升效果將更明顯。for (int i = 0, j = collection.GetIndexOf(item); i < j; i++)
　需要說明的是：這種寫法對于CLR集合類的Count屬性沒有意義，原因是編譯器已經(jīng)按這種方式做了特別的優(yōu)化。
　1.7.2 拼裝字符串
　拼裝好之后再刪除是很低效的寫法。有些方法其循環(huán)長度在大部分情況下為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 避免兩次檢索集合元素
　獲取集合元素時，有時需要檢查元素是否存在。通常的做法是先調(diào)用ContainsKey（或Contains）方法，然后再獲取集合元素。這種寫法非常符合邏輯。
　但如果考慮效率，可以先直接獲取對象，然后判斷對象是否為null來確定元素是否存在。對于Hashtable，這可以節(jié)省一次GetHashCode調(diào)用和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 避免兩次類型轉(zhuǎn)換
　考慮如下示例，其中包含了兩處類型轉(zhuǎn)換： if (obj is SomeType)
{
SomeType st = (SomeType)obj;
st.SomeTypeMethod();
}


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


1.8 Hashtable
　 Hashtable是一種使用非常頻繁的基礎(chǔ)集合類型。需要理解影響 Hashtable的效率有兩個因素：一是散列碼（GetHashCode方法），二是等值比較（Equals方法）。Hashtable首先使用鍵的散 列碼將對象分布到不同的存儲桶中，隨后在該特定的存儲桶中使用鍵的Equals方法進行查找。
　良好的散列碼是第一位的因素，最理想的情況是每個不同的鍵都有不同的散列碼。Equals方法也很重要，因為散列只需要做一次，而存儲桶中查找鍵可能需要做多次。從實際經(jīng)驗看，使用Hashtable時，Equals方法的消耗一般會占到一半以上。

System.Object 類提供了默認的GetHashCode實現(xiàn)，使用對象在內(nèi)存中的地址作為散列碼。我們 遇到過一個用Hashtable來緩存對象的例子，每次根據(jù)傳遞的OQL表達式構(gòu)造出一個ExpressionList對象，再調(diào)用 QueryCompiler的方法編譯得到CompiledQuery對象。以ExpressionList對象和CompiledQuery對象作為鍵 值對存儲到Hashtable中。ExpressionList對象沒有重載GetHashCode實現(xiàn)，其超類ArrayList也沒有，這樣最后用的 就是System.Object類的GetHashCode實現(xiàn)。由于ExpressionList對象會每次構(gòu)造，因此它的HashCode每次都不 同，所以這個CompiledQueryCache根本就沒有起到預(yù)想的作用。這個小小的疏漏帶來了重大的性能問題，由于解析OQL表達式頻繁發(fā)生，導致 CompiledQueryCache不斷增長，造成服務(wù)器內(nèi)存泄漏！解決這個問題的最簡單方法就是提供一個常量實現(xiàn)，例如讓散列碼為常量0。雖然這會導 致所有對象匯聚到同一個存儲桶中，效率不高，但至少可以解決掉內(nèi)存泄漏問題。當然，最終還是會實現(xiàn)一個高效的GetHashCode方法的。
　以上介紹這些Hashtable機理，主要是希望大家理解：如果使用Hashtable，你應(yīng)該檢查一下對象是否提供了適當?shù)腉etHashCode和Equals方法實現(xiàn)。否則，有可能出現(xiàn)效率不高或者與預(yù)期行為不符的情況。

　2. Ado.Net

2.1 應(yīng)用Ado.net的一些思考原則
　　1. 根據(jù)數(shù)據(jù)使用的方式來設(shè)計數(shù)據(jù)訪問層
　　2. 緩存數(shù)據(jù)，避免不必要的操作
　　3. 使用服務(wù)帳戶進行連接
　　4. 必要時申請，盡早釋放
　　5. 關(guān)閉可關(guān)閉的資源
　　6. 減少往返
　　7. 僅返回需要的數(shù)據(jù)
　　8. 選擇適當?shù)氖聞?wù)類型
　　9. 使用存儲過程

2.2 Connection
　數(shù)據(jù)庫連接是一種共享資源，并且打開和關(guān)閉的開銷較大。Ado.net默 認啟用了連接池機制，關(guān)閉連接不會真的關(guān)閉物理連接，而只是把連接放回到連接池中。因為池中共享的連接資源始終是有限的，如果在使用連接后不盡快關(guān)閉連 接，那么就有可能導致申請連接的線程被阻塞住，影響整個系統(tǒng)的性能表現(xiàn)。
　2.2.1 在方法中打開和關(guān)閉連接
　這個原則有幾層含義：
　　1. 主要目的是為了做到必要時申請和盡早釋放
　　2. 不要在類的構(gòu)造函數(shù)中打開連接、在析構(gòu)函數(shù)中釋放連接。因為這將依賴于垃圾回收，而垃圾回收只受內(nèi)存影響，回收時機不定
　　3. 不要在方法之間傳遞連接，這往往導致連接保持打開的時間過長

這里強調(diào)一下在方法之間傳遞連接的危害：曾經(jīng)在壓力測試中遇到過一個測試案例，當增大用戶數(shù)的時候，這個案例要比 別的案例早很久就用掉連接池中的所有連接。經(jīng)分析，就是因為A方法把一個打開的連接傳遞到了B方法，而B方法又調(diào)用了一個自行打開和關(guān)閉連接的C方法。在 A方法的整個運行期間，它至少需要占用兩條連接才能夠成功工作，并且其中的一條連接占用時間還特別長，所以造成連接池資源緊張，影響了整個系統(tǒng)的可伸縮 性！

2.2.2 顯式關(guān)閉連接
　Connection對象本身在垃圾回收時可以被關(guān)閉，而依賴垃圾回收是很不好的策略。推薦使用using語句顯式關(guān)閉連接，如下例：using (SqlConnection conn = new SqlConnection(connString))
{
conn.Open();

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


2.2.3 確保連接池啟用
　Ado.net是為每個不同的連接串建立連接池，因此應(yīng)該確保連接串不會出現(xiàn)與具體用戶相關(guān)的信息。另外，要注意連接串是大小寫敏感的。
　2.2.4 不要緩存連接
　例如，把連接緩存到Session或Application中。在啟用連接池的情況下，這種做法沒有任何意義。
　2.3 Command
　2.3.1 使用ExecuteScalar和ExecuteNonQuery
　 如果想返回像Count(*)、Sum(Price)或Avg(Quantity)那樣的單值，可以使用ExecuteScalar方法。 ExecuteScalar返回第一行第一列的值，將結(jié)果集作為標量值返回。因為單獨一步就能完成，所以ExecuteScalar不僅簡化了代碼，還提 高了性能。
　使用不返回行的SQL語句時，例如修改數(shù)據(jù)（INSERT、UPDATE或DELETE）或僅返回輸出參數(shù)或返回值，請使用ExecuteNonQuery。這避免了用于創(chuàng)建空DataReader的任何不必要處理。
　2.3.2 使用Prepare
　當需要重復(fù)執(zhí)行同一SQL語句多次，可考慮使用Prepare方法提升效率。需要注意的是，如果只是執(zhí)行一次或兩次，則完全沒有必要。例如：
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語句需要先被編譯成執(zhí)行計劃，然后再執(zhí)行。如果使用綁定變量的方 式，那么這個執(zhí)行計劃就可以被后續(xù)執(zhí)行的SQL語句所復(fù)用。而如果直接把參數(shù)合并到了SQL語句中，由于參數(shù)值千變?nèi)f化，執(zhí)行計劃就難以被復(fù)用了。例如上 面Prepare一節(jié)給出的示例，如果把參數(shù)值直接寫到insert語句中，那么上面的四次調(diào)用將需要編譯四次執(zhí)行計劃。
　為避免這種情況造成性能損失，要求一律使用綁定變量方式。
　2.4 DataReader
　 DataReader最適合于訪問只讀的單向數(shù)據(jù)集。與DataSet不同，數(shù)據(jù)集并不全部在內(nèi)存中，而是隨不斷發(fā)出的read請求，一旦發(fā)現(xiàn)數(shù)據(jù)緩沖區(qū) 中的數(shù)據(jù)均被讀取，則從數(shù)據(jù)源傳輸一個數(shù)據(jù)緩沖區(qū)大小的數(shù)據(jù)塊過來。另外，DataReader保持連接，DataSet則與連接斷開。
　2.4.1 顯式關(guān)閉DataReader
　 與連接類似，也需要顯式關(guān)閉DataReader。另外，如果與DataReader關(guān)聯(lián)的Connection僅為DataReader服務(wù)的話，可考 慮使用Command對象的ExecuteReader(CommandBehavior.CloseConnection)方式。這可以保證當 DataReader關(guān)閉時，同時自動關(guān)閉Connection。
　2.4.2 用索引號訪問代替名稱索引號訪問屬性
　從Row中訪問某列屬性，使用索引號的方式比使用名稱方式有細微提高。如果會被頻繁調(diào)用，例如在循環(huán)中，那么可考慮此類優(yōu)化。示例如下：
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方法有細微提高，因為不需要做類型轉(zhuǎn)換。
　2.4.4 使用多數(shù)據(jù)集
　部分場景可以考慮一次返回多數(shù)據(jù)集來降低網(wǎng)絡(luò)交互次數(shù)，提升效率。示例如下：
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 利用索引加快查找行的效率
　如果需要反復(fù)查找行，建議增加索引。有兩種方式：
　1. 設(shè)置DataTable的PrimaryKey
　適用于按PrimaryKey查找行的情況。注意此時應(yīng)調(diào)用DataTable.Rows.Find方法，一般慣用的Select方法不能利用索引。
　2. 使用DataView
　適用于按Non-PrimaryKey查找行的情況?？蔀镈ataTable創(chuàng)建一個DataView，并通過SortOrder參數(shù)指示建立索引。此后使用Find或FindRows查找行。

3.1 減少往返行程（Reduce Round Trips）
　使用下面的方法可以減少Web服務(wù)器和Browser之間的往返行程：
　1. 為Browser啟用緩存
　如果呈現(xiàn)的內(nèi)容是靜態(tài)的或變化周期較長，應(yīng)啟用Browser緩存，避免發(fā)出冗余的http請求。

2. 緩沖頁面輸出
　如果可能，則盡量緩沖頁面輸出，處理結(jié)束后再一次傳送到客戶端，這可以避免頻繁傳遞 小塊內(nèi)容所造成的多次網(wǎng)絡(luò)交互。由于這種方式在頁面處理結(jié)束之前客戶端無法看到頁面內(nèi)容，因此如果一個頁面的尺寸較大的話，可考慮使用 Response.Flush方法。該方法強制輸出迄今為止在緩沖區(qū)中的內(nèi)容，你應(yīng)當采用合理的算法控制調(diào)用Response.Flush方法的次數(shù)。

3. 使用Server.Transfer重定向請求
　使用Server.Transfer方法重定向請 求優(yōu)于Response.Redirect方法。原因是Response.Redirect會向Broswer回送一個響應(yīng)頭，在響應(yīng)頭中指出重定向的 URL，之后Brower使用新的URL重新發(fā)出請求。而Server.Transfer方法直接是一個簡單的服務(wù)端調(diào)用，完全沒有這些開銷！
　需要注意Server.Transfer有局限性：第一，它會跳過安全檢查；第二，只適用于在同一Web應(yīng)用內(nèi)的頁面間跳轉(zhuǎn)。

3.2 避免阻塞和長時間的作業(yè)
　如果需要運行阻塞或長時間運行的操作，可以考慮使用異步調(diào)用的機制，以便Web服務(wù)器能夠繼續(xù)處理其它的請求。
　1. 使用異步方式調(diào)用Web服務(wù)和遠程對象
　只要有可能就要避免在請求的處理過程中對Web服務(wù)和遠程對象的同步調(diào)用，因為它占用的是的ASP.NET 線程池中的工作線程，這將直接影響Web服務(wù)器響應(yīng)其它請求的能力。

2. 考慮給不需要返回值的Web方法或遠程對象的方法添加OneWay屬性
　這種模式能讓Web Server調(diào)用之后就立即返回?？筛鶕?jù)實際情況決定是否使用這種方法。

3. 使用工作隊列
　將作業(yè)提交到服務(wù)器上的工作隊列中。客戶端通過發(fā)送請求來輪詢作業(yè)的執(zhí)行結(jié)果。

3.3 使用緩存
　緩存能在很大程度上決定ASP.NET應(yīng)用的最終性能。Asp.net支持頁面輸出緩存和頁面部分緩存，并提供Cache API，供應(yīng)用程序緩存自己的數(shù)據(jù)。是否使用緩存可考慮下面的要點：
　　1. 識別創(chuàng)建與訪問代價較大的數(shù)據(jù)
　　2. 評估需要緩存數(shù)據(jù)的易變性
　　3. 評估數(shù)據(jù)的使用頻次
　　4. 將要緩存數(shù)據(jù)中易變數(shù)據(jù)和不變數(shù)據(jù)分離，只緩存不變數(shù)據(jù)
　　5. 選擇合適的緩存機制（除Asp.net Cache外，Application state和Session state也可以作為緩存使用）

3.4 多線程
　1. 避免在請求處理過程中創(chuàng)建線程
　在執(zhí)行請求的過程中創(chuàng)建線程是一種代價較大的操作，會嚴重影響Web Server的性能。如果后續(xù)的操作必須用線程完成，建議通過thread pool來創(chuàng)建/管理線程。

2. 不要依賴線程數(shù)據(jù)槽或線程靜態(tài)變量
　由于執(zhí)行請求的線程是ASP.NET thread pool中的工作線程，同一個Client的兩次請求不一定由相同的線程來處理。

3. 避免阻塞處理請求的線程
　參考"避免阻塞和長時間的作業(yè)"小節(jié)。

4. 避免異步調(diào)用
　這和1的情況類似。異步調(diào)用會導致創(chuàng)建新的線程，增加服務(wù)器的負擔。所以，如果沒有并發(fā)的作業(yè)要執(zhí)行，就不要執(zhí)行異步調(diào)用。

3.5 系統(tǒng)資源
　　1. 考慮實現(xiàn)資源池以提升性能
　　2. 明確地調(diào)用Dispose或Close釋放系統(tǒng)資源
　　3. 不要緩存或長時間占用資源池中的資源
　　4. 盡可能晚的申請，盡可能早的釋放

3.6 頁面處理
　1. 盡量減小Page的尺寸
　包括縮短控件的名稱、CSS的class的名稱、去掉無謂空行和空格、禁用不需要的ViewState
　2. 啟用頁面輸出的緩沖區(qū)（Buffer）
　如果Buffer的機制被關(guān)閉，可以用下面的方法打開。
　使用程序打開頁面輸出緩存：
　Response.BufferOutput = true;

使用@Page開關(guān)打開頁面輸出緩沖機制：
　<%@ Page Buffer = "true" %>

使用Web.config或Machine.config配置文件的<pages>節(jié)點：
　<pages buffer="true" …>
　3. 利用Page.IsPostBack優(yōu)化頁面輸出
　4. 通過分離頁面的不同的內(nèi)容，來提高緩存效率和減少呈現(xiàn)的時間
　5. 優(yōu)化復(fù)雜和代價較大的循環(huán)
　6. 合理利用客戶端的計算資源，將一些操作轉(zhuǎn)移到客戶端進行

3.7 ViewState
　ViewState是Asp.net為服務(wù)端控件在頁面回傳之間跟蹤狀態(tài)信息而設(shè)計的一種機制。
　1. 關(guān)閉ViewState
　 如果不需要跟蹤頁面狀態(tài)，例如頁面不會 回傳（PostBack）、不需要處理服務(wù)端控件事件或者每次頁面刷新時都會重新計算控件內(nèi)容，那么就不需要用ViewState來記錄頁面狀態(tài)了。可以 對特定的WebControl設(shè)置EnableViewState屬性，也可以在頁面一級設(shè)置：
　<%@ Page EnableViewState="false" %>

2. 在恰當?shù)臅r間點初始化控件屬性
　ASP.NET的控件在執(zhí)行構(gòu)造函數(shù)、初始化的期間設(shè)置的屬性不會被跟蹤變化；而在初始化階段之后對屬性的修改都會被跟蹤，并最終記錄到IE頁面的__VIEWSTATE之中。所以，選擇合理的初始化控件屬性的執(zhí)行點，能有效的減小頁面尺寸。

3. 謹慎選擇放到ViewState中的內(nèi)容
　放到ViewState中的內(nèi)容會被序列化/反序列 化，Asp.net為String、Integer、Boolean等基本類型的序列化做了優(yōu)化，如果Array、ArrayList、 HashTable存儲的是基本類型效率也較高，但其它類型則需要提供類型轉(zhuǎn)換器（Type Converter），否則將使用代價昂貴的二進制序列化程序。

4.1 JScript性能優(yōu)化的基本原則
　1. 盡可能少地減少執(zhí)行次數(shù)。畢竟對解釋語言來說，每一個執(zhí)行步驟，都需要和解釋引擎做一次交互。
　2. 盡可能使用語言內(nèi)置的功能，比如串鏈接。
　3. 盡可能使用系統(tǒng)提供的API來進行優(yōu)化。因為這些API是編譯好的二進制代碼，執(zhí)行效率很高。
　4. 書寫最正確的代碼。容錯功能是要付出性能代價的。

javascript:
4.2 JScript語言本身的優(yōu)化
　4.2.1 變量
　1. 盡量使用局部變量。
　因為全局變量其實是全局對象的成員，而局部變量在棧上定義，優(yōu)先查找，性能相對于全局變量要高。

2. 盡量在一個語句中做定義變量和賦值。

3. 省略不必要的變量定義。
　如果變量的定義可以被一個常量替代，就直接使用常量。

4. 使用Object語法對對象賦值。
　Object的賦值語法在操作復(fù)雜對象時效率更高。
　例如，可以將下面的代碼：
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. 緩存對象查找的中間結(jié)果。
　因為JavaScript的解釋性，所以a.b.c.d.e，需要進行至少4次查詢操作，先檢查a再檢查a中的b，再檢查b中的c，如此往下。所以如果這樣的表達式重復(fù)出現(xiàn)，只要可能，應(yīng)該盡量少出現(xiàn)這樣的表達式，可以利用局部變量，把它放入一個臨時的地方進行查詢。

2. 緩存創(chuàng)建時間較長的對象。
　自定義高級對象和Date、RegExp對象在構(gòu)造時都會消耗大量時間。如果可以復(fù)用，應(yīng)采用緩存的方式。

4.2.3 字符串操作
　1. 使用"+=" 追加字符串，使用"+"來連接字符串。
　如果是追加字符串，最好使用s+=anotherStr操作，而不是要使用s=s+anotherStr。
　如果要連接多個字符串，應(yīng)該使用"+"，如：
　　s+=a;
　　s+=b;
　　s+=c;
　　應(yīng)該寫成
　　s+=a + b + c；

2. 連接大量的字符串，應(yīng)使用Array的join方法。
　如果是收集字符串，最好使用JavaScript數(shù)組緩存，最后使用join方法連接起來，如下：
var buf = new Array();
for (var i = 0; i < 100; i++)
{
buf.push(i.toString());
}

var all = buf.join("");


4.2.4 類型轉(zhuǎn)換
　1. 使用Math.floor()或者Math.round()將浮點數(shù)轉(zhuǎn)換成整型。
　浮點數(shù)轉(zhuǎn)換成整型，這個更容易出錯，很多人喜歡使用parseInt()，其實parseInt()是用于將字符串轉(zhuǎn)換成數(shù)字，而不是浮點數(shù)和整型之間的轉(zhuǎn)換，我們應(yīng)該使用Math.floor()或者Math.round()。
　對象查找中的問題不一樣，Math是內(nèi)部對象，所以Math.floor()其實并沒有多少查詢方法和調(diào)用的時間，速度是最快的。

2. 自定義的對象，推薦定義和使用toString()方法來進行類型轉(zhuǎn)換。
　對于自定義的對象，如果定義了toString()方法來進行類型轉(zhuǎn)換的話，推薦顯式調(diào)用toString()。因為內(nèi)部的操作在嘗試所有可能性之后，會嘗試對象的toString()方法嘗試能否轉(zhuǎn)化為String，所以直接調(diào)用這個方法效率會更高。

4.2.5 循環(huán)的優(yōu)化
　1. 盡可能少使用for(in)循環(huán)。
　在JavaScript中，我們可以使用for(;;),while(),for(in)三種循環(huán)，事實上，這三種循環(huán)中for(in)的效率極差，因為他需要查詢散列鍵，只要可以就應(yīng)該盡量少用。

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

3. 盡量減少循環(huán)內(nèi)的操作。
　循環(huán)內(nèi)的每個操作，都會被放大為循環(huán)次數(shù)的倍數(shù)。所以，大循環(huán)內(nèi)微小的改進，在性能的整體提升上都是可觀的。

4. 使用循環(huán)替代遞歸。
　相比循環(huán)，遞歸的效率更差一些。遞歸的優(yōu)點是在形式上更自然一些。所以，在不影響代碼的維護性的前提下，用循環(huán)替代遞歸。

4.2.6 其它方面
　1. 盡量使用語言內(nèi)置的語法。
　 "var arr = […];"和"var arr = new Array(…);"是等效的，但是前者的效能優(yōu)于后者。同樣，"var foo = {};"的方式也比"var foo = new Object();"快；"var reg = /../;"要比"var reg=new RegExp()"快。

2. 盡量不要使用eval。
　使用eval，相當于在運行時再次調(diào)用解釋引擎，對傳入的內(nèi)容解釋運行，需要消耗大量時間。

3. 使用prototype代替closure。
　使用closure在性能和內(nèi)存消耗上都是不利的。如果closure使用量過大，這就會成為一個問題。所以，盡量將：
　this.methodFoo = function()
　替換成：
　MyClass.protoype.methodFoo = function()
　和closure存在于對象實例之中不同，prototype存在于類中，被該類的所有的對象實例共享。

4. 避免使用with語句。
　With語句臨時擴展對象查找的范圍，節(jié)省了文字的錄入時間，但付出了更多的執(zhí)行時間。因為每個給出的名稱都要在全局范圍查找。所以，可以將下面的代碼：
with (document.formname)
{
field1.value = "one";
field2.value = "two";
}
變更為：

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


4.3 DOM相關(guān)
　4.3.1 創(chuàng)建DOM節(jié)點
　相比較通過document.write來給頁面生成內(nèi)容，找一個容器元素（比如指定一個div或者span）并設(shè)置他們的innerHTML效率更高。
　而設(shè)置innerHTML的方式比通過createElement方法創(chuàng)建節(jié)點的效率更高。事實上，設(shè)置元素的innerHTML是創(chuàng)建節(jié)點效率最高的一種方式。
　 如果必須使用createElement方法，而如果文檔中存在現(xiàn)成的樣板節(jié)點，應(yīng)該是用cloneNode()方法。因為使用 createElement()方法之后，你需要設(shè)置多次元素的屬性，使用cloneNode()則可以減少屬性的設(shè)置次數(shù)。同樣，如果需要創(chuàng)建很多元 素，應(yīng)該先準備一個樣板節(jié)點。

4.3.2 離線操作大型的DOM樹
　在添加一個復(fù)雜的DOM樹時，可以先構(gòu)造，構(gòu)造結(jié)束后再將其添加到DOM數(shù)的適當節(jié)點。這能夠節(jié)省界面刷新的時間。

同樣，在準備編輯一個復(fù)雜的樹時，可以先將樹從DOM樹上刪除，等編輯結(jié)束后再添加回來。

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

4.3.4 定時器
　如果針對的是不斷運行的代碼，不應(yīng)該使用setTimeout，而應(yīng)該用setInterval。setTimeout每次要重新設(shè)置一個定時器。

4.4 其他
　1. 盡量減小文件尺寸。
　將JScript文件中無關(guān)的空行、空格、注釋去掉，有助于減小JS文件的尺寸，提高下載的時間。（可以通過工具來支持代碼發(fā)布）
　2. 盡量不要在同一個Page內(nèi)同時引用JScript和VBScript引擎
　3. 將Page內(nèi)的JScript移入到單獨的JS文件中。
　4. 將Page內(nèi)的JScript放置在Page的最下面，有助于提高頁面的響應(yīng)速度。
　5. 利用cache，減少JScript文件的下載次數(shù)
　6. 在HTML內(nèi)書寫JScript文件的URL時，注意統(tǒng)一大小寫。這樣可以利用前面URL緩存的文件。
　7. 推薦使用JScript Lint檢查Javascript代碼。畢竟，對JScript引擎來說，最容易理解的JScript代碼，執(zhí)行的效率也就最高。