ASP.NET:

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

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

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

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

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

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

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

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

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

　　返回的記錄總數(shù)取決于要執(zhí)行查詢，例如，一個(gè)where條件可以限制返回的結(jié)果集的大小。因?yàn)樵诜猪摻缑嬷斜仨氁鶕?jù)數(shù)據(jù)集記錄的大小來計(jì)算總的頁數(shù)，所以必須要返回結(jié)果集的記錄數(shù)。例如，如果一共有1000000條記錄，如果用where條件就可以過濾成只返回1000條記錄，存儲(chǔ)過程的分頁邏輯應(yīng)該知道返回那些需要顯示的數(shù)據(jù)。

三、連接池

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

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

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

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

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

四、ASP.NET緩存API

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

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

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

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

五、預(yù)請求緩存

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

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

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

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

六、后臺(tái)處理

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

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

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

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

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

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

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

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

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

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

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

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

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

八、 用IIS6.0的Kernel Caching

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

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

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

　　除非你的CPU占用率太高了，才有必要用提升服務(wù)器性能的技巧。用gzip壓縮數(shù)據(jù)的方法可以減少你發(fā)送到服務(wù)端的數(shù)據(jù)量，也可以提高頁面的運(yùn)行速度，同時(shí)也減少了網(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的屬性對(duì)話中設(shè)置。IIS開發(fā)團(tuán)隊(duì)把gzip壓縮功能開發(fā)出來了，但他們卻忘了在管理員窗口中讓管理員能很方便的啟用它。要啟用gzip壓縮，你只能深入IIS6.0的xml配置文件中修改它的配置。

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

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

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

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

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



1. C#語言方面

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

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

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


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

　 這里有一個(gè)細(xì)節(jié)應(yīng)注意：StringBuilder 內(nèi)部 Buffer 的缺省值為 16 ，這個(gè)值實(shí)在太小。按 StringBuilder 的使用場景，Buffer 肯定得重新分配。經(jīng)驗(yàn)值一般用 256 作為 Buffer 的初值。當(dāng)然，如果能計(jì)算出最終生成字符串長度的話，則應(yīng)該按這個(gè)值來設(shè)定 Buffer 的初值。使用 new StringBuilder(256) 就將 Buffer 的初始長度設(shè)為了256。
　1.2.2 避免不必要的調(diào)用 ToUpper 或 ToLower 方法
　String是不變類，調(diào)用ToUpper或ToLower方法都會(huì)導(dǎo)致創(chuàng)建一個(gè)新的字符串。如果被頻繁調(diào)用，將導(dǎo)致頻繁創(chuàng)建字符串對(duì)象。這違背了前面講到的“避免頻繁創(chuàng)建對(duì)象”這一基本原則。
　例如，bool.Parse方法本身已經(jīng)是忽略大小寫的，調(diào)用時(shí)不要調(diào)用ToLower方法。
　另一個(gè)非常普遍的場景是字符串比較。高效的做法是使用 Compare 方法，這個(gè)方法可以做大小寫忽略的比較，并且不會(huì)創(chuàng)建新字符串。
　 還有一種情況是使用 HashTable 的時(shí)候，有時(shí)候無法保證傳遞 key 的大小寫是否符合預(yù)期，往往會(huì)把 key 強(qiáng)制轉(zhuǎn)換到大寫或小寫方法。實(shí)際上 HashTable 有不同的構(gòu)造形式，完全支持采用忽略大小寫的 key: new HashTable(StringComparer.OrdinalIgnoreCase)。
　1.2.3 最快的空串比較方法
　將String對(duì)象的Length屬性與0比較是最快的方法：if (str.Length == 0)
　其次是與String.Empty常量或空串比較：if (str == String.Empty)或if (str == "")
　注：C#在編譯時(shí)會(huì)將程序集中聲明的所有字符串常量放到保留池中（intern pool），相同常量不會(huì)重復(fù)分配。

1.3 多線程

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


通常情況下，應(yīng)減小同步的范圍，使系統(tǒng)獲得更好的性能。簡單將整個(gè)方法標(biāo)記為同步不是一個(gè)好主意，除非能確定方法中的每個(gè)代碼都需要受同步保護(hù)。
　1.3.1.2 同步策略
　使用 lock 進(jìn)行同步，同步對(duì)象可以選擇 Type、this 或?yàn)橥侥康膶ｉT構(gòu)造的成員變量。
　避免鎖定Type★
　 鎖定Type對(duì)象會(huì)影響同一進(jìn)程中所有AppDomain該類型的所有實(shí)例，這不僅可能導(dǎo)致嚴(yán)重的性能問題，還可能導(dǎo)致一些無法預(yù)期的行為。這是一個(gè)很不 好的習(xí)慣。即便對(duì)于一個(gè)只包含static方法的類型，也應(yīng)額外構(gòu)造一個(gè)static的成員變量，讓此成員變量作為鎖定對(duì)象。
　避免鎖定 this
　 鎖定 this 會(huì)影響該實(shí)例的所有方法。假設(shè)對(duì)象 obj 有 A 和 B 兩個(gè)方法，其中 A 方法使用 lock(this) 對(duì)方法中的某段代碼設(shè)置同步保護(hù)。現(xiàn)在，因?yàn)槟撤N原因，B 方法也開始使用 lock(this) 來設(shè)置同步保護(hù)了，并且可能為了完全不同的目的。這樣，A 方法就被干擾了，其行為可能無法預(yù)知。所以，作為一種良好的習(xí)慣，建議避免使用 lock(this) 這種方式。
　使用為同步目的專門構(gòu)造的成員變量
　這是推薦的做法。方式就是 new 一個(gè) object 對(duì)象， 該對(duì)象僅僅用于同步目的。
　如果有多個(gè)方法都需要同步，并且有不同的目的，那么就可以為些分別建立幾個(gè)同步成員變量。

1.3.1.4 集合同步
　C#為各種集合類型提供了兩種方便的同步機(jī)制：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 方法會(huì)返回一個(gè)可保證所有操作都是線程安全的相同集合對(duì)象。考慮 mySyncdAL[0] = mySyncdAL[0] + "test" 這一語句，讀和寫一共要用到兩個(gè)鎖。一般講，效率不高。推薦使用 SyncRoot 屬性，可以做比較精細(xì)的控制。

1.3.2 使用 ThreadStatic 替代 NameDataSlot ★
　存取 NameDataSlot 的 Thread.GetData 和 Thread.SetData 方法需要線程同步，涉及兩個(gè)鎖：一個(gè)是 LocalDataStore.SetData 方法需要在 AppDomain 一級(jí)加鎖，另一個(gè)是 ThreadNative.GetDomainLocalStore 方法需要在 Process 一級(jí)加鎖。如果一些底層的基礎(chǔ)服務(wù)使用了 NameDataSlot，將導(dǎo)致系統(tǒng)出現(xiàn)嚴(yán)重的伸縮性問題。
　規(guī)避這個(gè)問題的方法是使用 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)建對(duì)象internal IDictionary KeyTable
{
get
{
if ( this ._keyTable == null )
{
lock ( base ._lock)
{
if ( this ._keyTable == null )
{
this ._keyTable = new Hashtable();
}
}
}
return this ._keyTable;
}
}


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

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

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

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

1.7 基本代碼技巧
　這里描述一些應(yīng)用場景下，可以提高性能的基本代碼技巧。對(duì)處于關(guān)鍵路徑的代碼，進(jìn)行這類的優(yōu)化還是很有意義的。普通代碼可以不做要求，但養(yǎng)成一種好的習(xí)慣也是有意義的。
　1.7.1 循環(huán)寫法
　 可以把循環(huán)的判斷條件用局部變量記錄下來。局部變量往往被編譯器優(yōu)化為直接使用寄存器，相對(duì)于普通從堆或棧中分配的變量速度快。如果訪問的是復(fù)雜計(jì)算屬性 的話，提升效果將更明顯。for (int i = 0, j = collection.GetIndexOf(item); i < j; i++)
　需要說明的是：這種寫法對(duì)于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();


其實(shí)這種寫法非常自然，而且效率很高，完全不需要用個(gè)Remove方法繞來繞去。
　1.7.3 避免兩次檢索集合元素
　獲取集合元素時(shí)，有時(shí)需要檢查元素是否存在。通常的做法是先調(diào)用ContainsKey（或Contains）方法，然后再獲取集合元素。這種寫法非常符合邏輯。
　但如果考慮效率，可以先直接獲取對(duì)象，然后判斷對(duì)象是否為null來確定元素是否存在。對(duì)于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;
}


其實(shí)完全可用一行代碼完成：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的效率有兩個(gè)因素：一是散列碼（GetHashCode方法），二是等值比較（Equals方法）。Hashtable首先使用鍵的散 列碼將對(duì)象分布到不同的存儲(chǔ)桶中，隨后在該特定的存儲(chǔ)桶中使用鍵的Equals方法進(jìn)行查找。
　良好的散列碼是第一位的因素，最理想的情況是每個(gè)不同的鍵都有不同的散列碼。Equals方法也很重要，因?yàn)樯⒘兄恍枰鲆淮?，而存?chǔ)桶中查找鍵可能需要做多次。從實(shí)際經(jīng)驗(yàn)看，使用Hashtable時(shí)，Equals方法的消耗一般會(huì)占到一半以上。

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

　2. Ado.Net

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

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

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

2.2.2 顯式關(guān)閉連接
　Connection對(duì)象本身在垃圾回收時(shí)可以被關(guān)閉，而依賴?yá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是為每個(gè)不同的連接串建立連接池，因此應(yīng)該確保連接串不會(huì)出現(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é)果集作為標(biāo)量值返回。因?yàn)閱为?dú)一步就能完成，所以ExecuteScalar不僅簡化了代碼，還提 高了性能。
　使用不返回行的SQL語句時(shí)，例如修改數(shù)據(jù)（INSERT、UPDATE或DELETE）或僅返回輸出參數(shù)或返回值，請使用ExecuteNonQuery。這避免了用于創(chuàng)建空DataReader的任何不必要處理。
　2.3.2 使用Prepare
　當(dāng)需要重復(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í)行計(jì)劃，然后再執(zhí)行。如果使用綁定變量的方 式，那么這個(gè)執(zhí)行計(jì)劃就可以被后續(xù)執(zhí)行的SQL語句所復(fù)用。而如果直接把參數(shù)合并到了SQL語句中，由于參數(shù)值千變?nèi)f化，執(zhí)行計(jì)劃就難以被復(fù)用了。例如上 面Prepare一節(jié)給出的示例，如果把參數(shù)值直接寫到insert語句中，那么上面的四次調(diào)用將需要編譯四次執(zhí)行計(jì)劃。
　為避免這種情況造成性能損失，要求一律使用綁定變量方式。
　2.4 DataReader
　 DataReader最適合于訪問只讀的單向數(shù)據(jù)集。與DataSet不同，數(shù)據(jù)集并不全部在內(nèi)存中，而是隨不斷發(fā)出的read請求，一旦發(fā)現(xiàn)數(shù)據(jù)緩沖區(qū) 中的數(shù)據(jù)均被讀取，則從數(shù)據(jù)源傳輸一個(gè)數(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對(duì)象的ExecuteReader(CommandBehavior.CloseConnection)方式。這可以保證當(dāng) DataReader關(guān)閉時(shí)，同時(shí)自動(dòng)關(guān)閉Connection。
　2.4.2 用索引號(hào)訪問代替名稱索引號(hào)訪問屬性
　從Row中訪問某列屬性，使用索引號(hào)的方式比使用名稱方式有細(xì)微提高。如果會(huì)被頻繁調(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方法有細(xì)微提高，因?yàn)椴恍枰鲱愋娃D(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查找行的情況。注意此時(shí)應(yīng)調(diào)用DataTable.Rows.Find方法，一般慣用的Select方法不能利用索引。
　2. 使用DataView
　適用于按Non-PrimaryKey查找行的情況?？蔀镈ataTable創(chuàng)建一個(gè)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)容，因此如果一個(gè)頁面的尺寸較大的話，可考慮使用 Response.Flush方法。該方法強(qiáng)制輸出迄今為止在緩沖區(qū)中的內(nèi)容，你應(yīng)當(dāng)采用合理的算法控制調(diào)用Response.Flush方法的次數(shù)。

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

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

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

3. 使用工作隊(duì)列
　將作業(yè)提交到服務(wù)器上的工作隊(duì)列中?？蛻舳送ㄟ^發(fā)送請求來輪詢作業(yè)的執(zhí)行結(jié)果。

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

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

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

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

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

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

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

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

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

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

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

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

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

javascript:
4.2 JScript語言本身的優(yōu)化
　4.2.1 變量
　1. 盡量使用局部變量。
　因?yàn)槿肿兞科鋵?shí)是全局對(duì)象的成員，而局部變量在棧上定義，優(yōu)先查找，性能相對(duì)于全局變量要高。

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

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

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

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

4.2.3 字符串操作
　1. 使用"+=" 追加字符串，使用"+"來連接字符串。
　如果是追加字符串，最好使用s+=anotherStr操作，而不是要使用s=s+anotherStr。
　如果要連接多個(gè)字符串，應(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()或者M(jìn)ath.round()將浮點(diǎn)數(shù)轉(zhuǎn)換成整型。
　浮點(diǎn)數(shù)轉(zhuǎn)換成整型，這個(gè)更容易出錯(cuò)，很多人喜歡使用parseInt()，其實(shí)parseInt()是用于將字符串轉(zhuǎn)換成數(shù)字，而不是浮點(diǎn)數(shù)和整型之間的轉(zhuǎn)換，我們應(yīng)該使用Math.floor()或者M(jìn)ath.round()。
　對(duì)象查找中的問題不一樣，Math是內(nèi)部對(duì)象，所以Math.floor()其實(shí)并沒有多少查詢方法和調(diào)用的時(shí)間，速度是最快的。

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

4.2.5 循環(huán)的優(yōu)化
　1. 盡可能少使用for(in)循環(huán)。
　在JavaScript中，我們可以使用for(;;),while(),for(in)三種循環(huán)，事實(shí)上，這三種循環(huán)中for(in)的效率極差，因?yàn)樗枰樵兩⒘墟I，只要可以就應(yīng)該盡量少用。

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

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

4. 使用循環(huán)替代遞歸。
　相比循環(huán)，遞歸的效率更差一些。遞歸的優(yōu)點(diǎn)是在形式上更自然一些。所以，在不影響代碼的維護(hù)性的前提下，用循環(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，相當(dāng)于在運(yùn)行時(shí)再次調(diào)用解釋引擎，對(duì)傳入的內(nèi)容解釋運(yùn)行，需要消耗大量時(shí)間。

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

4. 避免使用with語句。
　With語句臨時(shí)擴(kuò)展對(duì)象查找的范圍，節(jié)省了文字的錄入時(shí)間，但付出了更多的執(zhí)行時(shí)間。因?yàn)槊總€(gè)給出的名稱都要在全局范圍查找。所以，可以將下面的代碼：
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é)點(diǎn)
　相比較通過document.write來給頁面生成內(nèi)容，找一個(gè)容器元素（比如指定一個(gè)div或者span）并設(shè)置他們的innerHTML效率更高。
　而設(shè)置innerHTML的方式比通過createElement方法創(chuàng)建節(jié)點(diǎn)的效率更高。事實(shí)上，設(shè)置元素的innerHTML是創(chuàng)建節(jié)點(diǎn)效率最高的一種方式。
　 如果必須使用createElement方法，而如果文檔中存在現(xiàn)成的樣板節(jié)點(diǎn)，應(yīng)該是用cloneNode()方法。因?yàn)槭褂?createElement()方法之后，你需要設(shè)置多次元素的屬性，使用cloneNode()則可以減少屬性的設(shè)置次數(shù)。同樣，如果需要?jiǎng)?chuàng)建很多元 素，應(yīng)該先準(zhǔn)備一個(gè)樣板節(jié)點(diǎn)。

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

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

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

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

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

最新評(píng)論