版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領
文檔簡介
C#.NET性能優(yōu)化總結垃圾回收垃圾回收解放了手工管理對象的工作,提高了程序的健壯性,但副作用就是程序代碼可能對于對象創(chuàng)建變得隨意。避免不必要的對象創(chuàng)建由于垃圾回收的代價較高,所以C#程序開發(fā)要遵循的一個基本原則就是避免不必要的對象創(chuàng)建。以下列舉一些常見的情形。避免循環(huán)創(chuàng)建對象。如果對象并不會隨每次循環(huán)而改變狀態(tài),那么在循環(huán)中反復創(chuàng)建對象將帶來性能損耗。高效的做法是將對象提到循環(huán)外面創(chuàng)建。在需要邏輯分支中創(chuàng)建對象。如果對象只在某些邏輯分支中才被用到,那么應只在該邏輯分支中創(chuàng)建對象。使用常量避免創(chuàng)建對象。程序中不應出現(xiàn)如newDecimal(0)之類的代碼,這會導致小對象頻繁創(chuàng)建及回收,正確的做法是使用Decimal.Zero常量。我們有設計自己的類時,也可以學習這個設計手法,應用到類似的場景中。使用StringBuilder做字符串連接。不要使用空析構函數(shù)如果類包含析構函數(shù),由創(chuàng)建對象時會在Finalize隊列中添加對象的引用,以保證當對象無法可達時,仍然可以調(diào)用到Finalize方法。垃圾回收器在運行期間,會啟動一個低優(yōu)先級的線程處理該隊列。相比之下,沒有析構函數(shù)的對象就沒有這些消耗。如果析構函數(shù)為空,這個消耗就毫無意義,只會導致性能降低。因此,不要使用空的析構函數(shù)。在實際情況中,許多曾在析構函數(shù)中包含處理代碼,但后來因為種種原因被注釋掉或者刪除掉了,只留下一個空殼,此時應注意把析構函數(shù)本身注釋掉或刪除掉。實現(xiàn)Idisposable接口垃圾回收事實上只支持托管內(nèi)在的回收,對于其他的非托管資源,例如WindowGDI句柄或數(shù)據(jù)庫連接,在析構函數(shù)中釋放這些資源有很大問題。原因是垃圾回收依賴于內(nèi)存在緊張的情況,雖然數(shù)據(jù)庫連接可能已瀕臨耗盡,但如果內(nèi)存還很充足的話,垃圾回收是不會運行的。C#的IDisposable接口是一種顯式釋放資源的機制。通過提供using語句,還簡化了使用方式(編譯器自動生成try...finally塊,并在finally塊中調(diào)用Dispose方法)。對于申請非托管資源對象,應為其實現(xiàn)IDisposable接口,以保證資源一旦超出using語句范圍,即得到及時釋放。這對于構造健壯且性能優(yōu)良的程序非常有意義。為防止對象的Dispose方法不被調(diào)用的情況發(fā)生,一般還要提供析構函數(shù),兩者調(diào)用一個處理資源釋放的公共方法。同時,Dispose方法應調(diào)用System.GC.SuppressFinalize(this),告訴垃圾回收器無需再處理Finalize方法了。String操作使用StringBuilder做字符串連接String是不變類,使用+操作連接字符串將會導致創(chuàng)建一個新的字符串。如果字符串連接次數(shù)不是固定的,例如在一個循環(huán)中,則應該使用StringBuilder類來做字符串連接工作。因為StringBuilder內(nèi)部有一個StringBuffer,連接操作不會每次分配新的字符串空間。只有當連接后的字符串超出Buffer大小時,才會申請新的Buffer空間。典型代碼如下:StringBuildersb=newStringBuilder(256);for(inti=0;i<Results.Count;i++){sb.Append(Results[i]);}如果連接次數(shù)是固定的并且只有幾次,此時應該直接用+號連接,保持程序簡潔易讀。實際上,編譯器已經(jīng)做了優(yōu)化,會依據(jù)加號次數(shù)調(diào)用不同參數(shù)個數(shù)的String.Concat方法。例如:Stringstr=str1+str2+str3+str4;會被編譯為String.Concat(str1,str2,str3,str4)。該方法內(nèi)部會計算總的String長度,僅分配一次,并不會如通常想象的那樣分配三次。作為一個經(jīng)驗值,當字符串連接操作達到10次以上時,則應該使用StringBuilder。這里有一個細節(jié)應注意:StringBuilder內(nèi)部Buffe的缺省值為16,這個值實在太小。按StringBuilder的使用場景,Buffer肯定得重新分配。經(jīng)驗值一般用256作為Buffer的初值。當然,如果能計算出最終生成字符串長度的話,則應該按這個值來設定Buffer的初值。使用newStringBuilder(256)就將Buffer的初始長度設為了256。避免不必要的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)建新字符串。例:conststringC_VALUE="COMPARE";if(String.Compare(sVariable,C_VALUE,true)==0){Console.Write("SAME");}還有一種情況是使用HashTable的時候,有時候無法保證傳遞key的大小寫是否符合預期,往往會把key強制轉換到大寫或小寫方法。實際上HashTable有不同的構造形式,完全支持采用忽略大小寫的key:newHashTable(StringComparer.OrdinalIgnoreCase)。最快的空串比較方法將String對象的Length屬性與0比較是最快的方法:if(str.Length==0)其次是與String.Empty常量或空串比較:if(str==String.Empty)或if(str=="")注:C#在編譯時會將程序集中聲明的所有字符串常量放到保留池中(internpool),相同常量不會重復分配。多線程線程同步線程同步是編寫多線程程序需要首先考慮問題。C#為同步提供了Monitor、Mutex、AutoResetEvent和ManualResetEvent對象來分別包裝Win32的臨界區(qū)、互斥對象和事件對象這幾種基礎的同步機制。C#還提供了一個lock語句,方便使用,編譯器會自動生成適當?shù)腗onitor.Enter和Monitor.Exit調(diào)用。同步粒度同步粒度可以是整個方法,也可以是方法中某一段代碼。為方法指定MethodImplOptions.Synchronized屬性將標記對整個方法同步。例如:[MethodImpl(MethodImplOptions.Synchronized)]publicstaticSerialManagerGetInstance(){if(instance==null){ instance=newSerialManager(); }returninstance;}通常情況下,應減小同步的范圍,使系統(tǒng)獲得更好的性能。簡單將整個方法標記為同步不是一個好主意,除非能確定方法中的每個代碼都需要受同步保護。同步策略使用lock進行同步,同步對象可以選擇Type、this或為同步目的專門構造的成員變量。避免鎖定Type★鎖定Type對象會影響同一進程中所有AppDomain該類型的所有實例,這不僅可能導致嚴重的性能問題,還可能導致一些無法預期的行為。這是一個很不好的習慣。即便對于一個只包含static方法的類型,也應額外構造一個static的成員變量,讓此成員變量作為鎖定對象。避免鎖定this鎖定this會影響該實例的所有方法。假設對象obj有A和B兩個方法,其中A方法使用lock(this)對方法中的某段代碼設置同步保護?,F(xiàn)在,因為某種原因,B方法也開始使用lock(this)來設置同步保護了,并且可能為了完全不同的目的。這樣,A方法就被干擾了,其行為可能無法預知。所以,作為一種良好的習慣,建議避免使用lock(this)這種方式。使用為同步目的專門構造的成員變量這是推薦的做法。方式就是new一個object對象,該對象僅僅用于同步目的。如果有多個方法都需要同步,并且有不同的目的,那么就可以為些分別建立幾個同步成員變量。集合同步C#為各種集合類型提供了兩種方便的同步機制:Synchronized包裝器和SyncRoot屬性。//CreatesandinitializesanewArrayListArrayListmyAL=newArrayList();myAL.Add("The");myAL.Add("quick");myAL.Add("brown");myAL.Add("fox");//CreatesasynchronizedwrapperaroundtheArrayListArrayListmySyncdAL=ArrayList.Synchronized(myAL);調(diào)用Synchronized方法會返回一個可保證所有操作都是線程安全的相同集合對象??紤]mySyncdAL[0]=mySyncdAL[0]+"test"這一語句,讀和寫一共要用到兩個鎖。一般講,效率不高。推薦使用SyncRoot屬性,可以做比較精細的控制。使用ThreadStatic替代NameDataSlot★存取NameDataSlot的Thread.GetData和Thread.SetData方法需要線程同步,涉及兩個鎖:一個是LocalDataStore.SetData方法需要在AppDomain一級加鎖,另一個是ThreadNative.GetDomainLocalStore方法需要在Process一級加鎖。如果一些底層的基礎服務使用了NameDataSlot,將導致系統(tǒng)出現(xiàn)嚴重的伸縮性問題。規(guī)避這個問題的方法是使用ThreadStatic變量。示例如下:publicsealedclassInvokeContext{[ThreadStatic]privatestaticInvokeContextcurrent;privateHashtablemaps=newHashtable();}多線程編程技巧使用DoubleCheck技術創(chuàng)建對象internalIDictionaryKeyTable{get{if(this._keyTable==null){lock(base._lock){if(this._keyTable==null){ this._keyTable=newHashtable(); }}}returnthis._keyTable;}}創(chuàng)建單例對象是很常見的一種編程情況。一般在lock語句后就會直接創(chuàng)建對象了,但這不夠安全。因為在lock鎖定對象之前,可能已經(jīng)有多個線程進入到了第一個if語句中。如果不加第二個if語句,則單例對象會被重復創(chuàng)建,新的實例替代掉舊的實例。如果單例對象中已有數(shù)據(jù)不允許被破壞或者別的什么原因,則應考慮使用DoubleCheck技術。類型系統(tǒng)避免無意義的變量初始化CLR保證所有對象在訪問前已初始化,其做法是將分配的內(nèi)存清零。因此,不需要將變量重新初始化為0、false或null。需要注意的是:方法中的局部變量不是從堆而是從棧上分配,所以C#不會做清零工作。如果使用了未賦值的局部變量,編譯期間即會報警。不要因為有這個印象而對所有類的成員變量也做賦值動作,兩者的機理完全不同。ValueType和ReferenceType以引用方式傳遞值類型參數(shù)值類型從調(diào)用棧分配,引用類型從托管堆分配。當值類型用作方法參數(shù)時,默認會進行參數(shù)值復制,這抵消了值類型分配效率上的優(yōu)勢。作為一項基本技巧,以引用方式傳遞值類型參數(shù)可以提高性能。為ValueType提供Equals方法.NET默認實現(xiàn)的ValueType.Equals方法使用了反射技術,依靠反射來獲得所有成員變量值做比較,這個效率極低。如果我們編寫的值對象其Equals方法要被用到(例如將值對象放到HashTable中),那么就應該重載Equals方法。publicstructRectangle{ publicdoubleLength; publicdoubleBreadth; publicoverrideboolEquals(objectob) { if(obisRectangle) returnEquels((Rectangle)ob)) else returnfalse; } privateboolEquals(Rectanglerect) { returnthis.Length==rect.Length&&this.Breadth==rect.Breach; }}避免裝箱和拆箱C#可以在值類型和引用類型之間自動轉換,方法是裝箱和拆箱。裝箱需要從堆上分配對象并拷貝值,有一定性能消耗。如果這一過程發(fā)生在循環(huán)中或是作為底層方法被頻繁調(diào)用,則應該警惕累計的效應。一種經(jīng)常的情形出現(xiàn)在使用集合類型時。例如://避免如下操作ArrayListal=newArrayList();for(inti=0;i<1000;i++){ //裝箱操作al.Add(i);}//拆箱操作intf=(int)al[0];但是得當心,如果你像使用引用類型那么頻繁的使用一個值類型的話,值類型的優(yōu)勢會很快被耗盡。比如,把一個值類型壓到一個含有對象類型的群集。這叫做裝箱,很耗用處理器周期,尤其是當你的代碼在把它作為值(對它進行數(shù)學運算)和把它作為引用之間來回運行時。盡可能使用最合適的類型盡可能使用最合適的類型來描述數(shù)據(jù),從而減少類型轉換。使用泛型來創(chuàng)建群集和其它的數(shù)據(jù)結構,這樣,在運行時,它們就可以被實例化來存儲剛好合適的類型。這節(jié)省了裝箱/拆箱和類型轉換的時間。在C#中使用as,而不是is。關鍵字is用來查看引用是否可以被作為某個具體的類型,但是并不返回轉換到這個類型的引用。所以,通常當你從is獲得一個正的結果時,你首先應該cast——有效地執(zhí)行兩次cast。采用as關鍵詞時,如果可用,則返回cast為新類型的引用;否則返回null。你可以查看null然后做你喜歡做的事情。整體來說,as方法要比is方法快50%。異常處理不要吃掉異常關于異常處理的最重要原則就是:不要吃掉異常。這個問題與性能無關,但對于編寫健壯和易于排錯的程序非常重要。這個原則換一種說法,就是不要捕獲那些你不能處理的異常。吃掉異常是極不好的習慣,因為你消除了解決問題的線索。一旦出現(xiàn)錯誤,定位問題將非常困難。除了這種完全吃掉異常的方式外,只將異常信息寫入日志文件但并不做更多處理的做法也同樣不妥。不要吃掉異常信息有些代碼雖然拋出了異常,但卻把異常信息吃掉了。為異常披露詳盡的信息是程序員的職責所在。如果不能在保留原始異常信息含義的前提下附加更豐富和更人性化的內(nèi)容,那么讓原始的異常信息直接展示也要強得多。千萬不要吃掉異常信息。避免不必要的拋出異常拋出異常和捕獲異常屬于消耗比較大的操作,在可能的情況下,應通過完善程序邏輯避免拋出不必要的異常。與此相關的一個傾向是利用異常來控制處理邏輯。盡管對于極少數(shù)的情況,這可能獲得更為優(yōu)雅的解決方案,但通常而言應該避免。避免不必要的重新拋出異常如果是為了包裝異常的目的(即加入更多信息后包裝成新異常),那么是合理的。但是有不少代碼,捕獲異常沒有做任何處理就再次拋出,這將無謂地增加一次捕獲異常和拋出異常的消耗,對性能有傷害。捕獲指定的異常不要使用通用的System.Exception//避免try{}catch(Exceptionexc){}//推薦try{}catch(System.NullReferenceExceptionexc){}catch(System.ArgumentOutOfRangeExceptionexc){}catch(System.InvalidCastExceptionexc){}要在finally里釋放占用的資源使用Try...catch...finally時,要在finally里釋放占用的資源如:連接,文件流等,不然在Catch到錯誤后占用的資源不能釋放。
反射反射是一項很基礎的技術,它將編譯期間的靜態(tài)綁定轉換為延遲到運行期間的動態(tài)綁定。在很多場景下(特別是類框架的設計),可以獲得靈活易于擴展的架構。但帶來的問題是與靜態(tài)綁定相比,動態(tài)綁定會對性能造成較大的傷害。反射分類typecomparison:類型判斷,主要包括is和typeof兩個操作符及對象實例上的GetType調(diào)用。這是最輕型的消耗,可以無需考慮優(yōu)化問題。注意typeof運算符比對象實例上的GetType方法要快,只要可能則優(yōu)先使用typeof運算符。memberenumeration:成員枚舉,用于訪問反射相關的元數(shù)據(jù)信息,例如Assembly.GetModule、Module.GetType、Type對象上的IsInterface、IsPublic、GetMethod、GetMethods、GetProperty、GetProperties、GetConstructor調(diào)用等。盡管元數(shù)據(jù)都會被CLR緩存,但部分方法的調(diào)用消耗仍非常大,不過這類方法調(diào)用頻度不會很高,所以總體看性能損失程度中等。memberinvocation:成員調(diào)用,包括動態(tài)創(chuàng)建對象及動態(tài)調(diào)用對象方法,主要有Activator.CreateInstance、Type.InvokeMember等。動態(tài)創(chuàng)建對象C#主要支持5種動態(tài)創(chuàng)建對象的方式:1.Type.InvokeMember2.ContructorInfo.Invoke3.Activator.CreateInstance(Type)4.Activator.CreateInstance(assemblyName,typeName)5.Assembly.CreateInstance(typeName)最快的是方式3,與DirectCreate的差異在一個數(shù)量級之內(nèi),約慢7倍的水平。其他方式,至少在40倍以上,最慢的是方式4,要慢三個數(shù)量級。動態(tài)方法調(diào)用方法調(diào)用分為編譯期的早期綁定和運行期的動態(tài)綁定兩種,稱為Early-BoundInvocation和Late-BoundInvocation。Early-BoundInvocation可細分為Direct-call、Interface-call和Delegate-call。Late-BoundInvocation主要有Type.InvokeMember和MethodBase.Invoke,還可以通過使用LCG(LightweightCodeGeneration)技術生成IL代碼來實現(xiàn)動態(tài)調(diào)用。從測試結果看,相比DirectCall,Type.InvokeMember要接近慢三個數(shù)量級;MethodBase.Invoke雖然比Type.InvokeMember要快三倍,但比DirectCall仍慢270倍左右??梢妱討B(tài)方法調(diào)用的性能是非常低下的。我們的建議是:除非要滿足特定的需求,否則不要使用。推薦的使用原則1.如果可能,則避免使用反射和動態(tài)綁定2.使用接口調(diào)用方式將動態(tài)綁定改造為早期綁定3.使用Activator.CreateInstance(Type)方式動態(tài)創(chuàng)建對象4.使用typeof操作符代替GetType調(diào)用5.在已獲得Type的情況下,使用Assembly.CreateInstance(type.FullName)?;敬a技巧這里描述一些應用場景下,可以提高性能的基本代碼技巧。對處于關鍵路徑的代碼,進行這類的優(yōu)化還是很有意義的。普通代碼可以不做要求,但養(yǎng)成一種好的習慣也是有意義的。循環(huán)寫法可以把循環(huán)的判斷條件用局部變量記錄下來。局部變量往往被編譯器優(yōu)化為直接使用寄存器,相對于普通從堆或棧中分配的變量速度快。如果訪問的是復雜計算屬性的話,提升效果將更明顯。for(inti=0,j=collection.GetIndexOf(item);i<j;i++)需要說明的是:這種寫法對于CLR集合類的Count屬性沒有意義,原因是編譯器已經(jīng)按這種方式做了特別的優(yōu)化。拼裝字符串拼裝好之后再刪除是很低效的寫法。有些方法其循環(huán)長度在大部分情況下為1,這種寫法的低效就更為明顯了://避免publicstaticstringToString(MetadataKeyentityKey){stringstr="";object[]vals=entityKey.values;for(inti=0;i<vals.Length;i++){str+=","+vals[i].ToString();}returnstr==""?"":str.Remove(0,1);}推薦下面的寫法://推薦if(str.Length==0)str=vals[i].ToString();elsestr+=","+vals[i].ToString();其實這種寫法非常自然,而且效率很高,完全不需要用個Remove方法繞來繞去。避免兩次檢索集合元素獲取集合元素時,有時需要檢查元素是否存在。通常的做法是先調(diào)用ContainsKey(或Contains)方法,然后再獲取集合元素。這種寫法非常符合邏輯。但如果考慮效率,可以先直接獲取對象,然后判斷對象是否為null來確定元素是否存在。對于Hashtable,這可以節(jié)省一次GetHashCode調(diào)用和n次Equals比較。如下面的示例://避免publicIDataGetItemByID(Guidid){IDatadata1=null;if(this.idTable.ContainsKey(id.ToString()){data1=this.idTable[id.ToString()]asIData;}returndata1;}其實完全可用一行代碼完成:returnthis.idTable[id]asIData;避免兩次類型轉換考慮如下示例,其中包含了兩處類型轉換://避免if(objisSomeType){SomeTypest=(SomeType)obj;st.SomeTypeMethod();}效率更高的做法如下://推薦SomeTypest=objasSomeType;if(st!=null){st.SomeTypeMethod();}為字符串容器聲明常量為字符串容器申明變量,不要直接把字符封裝在雙引號“”里面。//避免MyObjectobj=newMyObject();obj.Status="ACTIVE";//推薦conststringC_STATUS="ACTIVE";MyObjectobj=newMyObject();obj.Status=C_STATUS;使用StringBuilder用StringBuilder代替使用字符串連接符“+”//避免StringsXML="";sXML+="";sXML+="Data";sXML+="";sXML+="";//推薦StringBuildersbXML=newStringBuilder();sbXML.Append("");sbXML.Append("");sbXML.Append("Data");sbXML.Append("");sbXML.Append("");避免在循環(huán)體里聲明變量應該在循環(huán)體外聲明變量,在循環(huán)體里初始化。//避免for(inti=0;i<10;i++){SomeClassobjSC=newSomeClass();}//推薦SomeClassobjSC=null;for(inti=0;i<10;i++){objSC=newSomeClass();)HashtableHashtable機制Hashtable是一種使用非常頻繁的基礎集合類型。需要理解影響Hashtable的效率有兩個因素:一是散列碼(GetHashCode方法),二是等值比較(Equals方法)。Hashtable首先使用鍵的散列碼將對象分布到不同的存儲桶中,隨后在該特定的存儲桶中使用鍵的Equals方法進行查找。良好的散列碼是第一位的因素,最理想的情況是每個不同的鍵都有不同的散列碼。Equals方法也很重要,因為散列只需要做一次,而存儲桶中查找鍵可能需要做多次。從實際經(jīng)驗看,使用Hashtable時,Equals方法的消耗一般會占到一半以上。System.Object類提供了默認的GetHashCode實現(xiàn),使用對象在內(nèi)存中的地址作為散列碼。我們遇到過一個用Hashtable來緩存對象的例子,每次根據(jù)傳遞的OQL表達式構造出一個ExpressionList對象,再調(diào)用QueryCompiler的方法編譯得到CompiledQuery對象。以ExpressionList對象和CompiledQuery對象作為鍵值對存儲到Hashtable中。ExpressionList對象沒有重載GetHashCode實現(xiàn),其超類ArrayList也沒有,這樣最后用的就是System.Object類的GetHashCode實現(xiàn)。由于ExpressionList對象會每次構造,因此它的HashCode每次都不同,所以這個CompiledQueryCache根本就沒有起到預想的作用。這個小小的疏漏帶來了重大的性能問題,由于解析OQL表達式頻繁發(fā)生,導致CompiledQueryCache不斷增長,造成服務器內(nèi)存泄漏。解決這個問題的最簡單方法就是提供一個常量實現(xiàn),例如讓散列碼為常量0。雖然這會導致所有對象匯聚到同一個存儲桶中,效率不高,但至少可以解決掉內(nèi)存泄漏問題。當然,最終還是會實現(xiàn)一個高效的GetHashCode方法的。以上介紹這些Hashtable機理,主要是希望大家理解:如果使用Hashtable,你應該檢查一下對象是否提供了適當?shù)腉etHashCode和Equals方法實現(xiàn)。否則,有可能出現(xiàn)效率不高或者與預期行為不符的情況。使用HashTale代替其他字典集合類型的情形其他字典集合類型(如StringDictionary,NameValueCollection,HybridCollection),存放少量數(shù)據(jù)的時候可以使用HashTable。很多非泛型集合類都有對應的泛型集合類,下面是常用的非泛型集合類以及對應的泛型集合類:非泛型集合類泛型集合類ArrayListList<T>HashTableDIctionary<T>QueueQueue<T>StackStack<T>SortedListSortedList<T>我們用的比較多的非泛型集合類主要有ArrayList類和HashTable類。我們經(jīng)常用HashTable來存儲將要寫入到數(shù)據(jù)庫或者返回的信息,在這之間要不斷的進行類型的轉化,增加了系統(tǒng)裝箱和拆箱的負擔,如果我們操縱的數(shù)據(jù)類型相對確定的化用Dictionary<TKey,TValue>集合類來存儲數(shù)據(jù)就方便多了,例如我們需要在電子商務網(wǎng)站中存儲用戶的購物車信息(商品名,對應的商品個數(shù))時,完全可以用Dictionary<string,int>來存儲購物車信息,而不需要任何的類型轉化。避免使用ArrayList因為任何對象添加到ArrayList都要封箱為System.Object類型,從ArrayList取出數(shù)據(jù)時,要拆箱回實際的類型。建議使用自定義的集合類型代替ArrayList。.NET2.0提供了一個新的類型,叫泛型,這是一個強類型,使用泛型集合就可以避免了封箱和拆箱的發(fā)生,提高了性能。從XML對象讀取數(shù)據(jù)如果只是從XML對象讀取數(shù)據(jù),用只讀的XPathDocument代替XMLDocument,可以提高性能。//避免XmlDocumentxmld=newXmlDocument();xmld.LoadXml(sXML);txtName.Text=xmld.SelectSingleNode("/packet/child").InnerText;//推薦XpathDocumentxmldContext=newXPathDocument(newStringReader(oContext.Value));XPathNavigatorxnav=xmldContext.CreateNavigator();XPathNodeIteratorxpNodeIter=xnav.Select("packet/child");iCount=xpNodeIter.Count;xpNodeIter=xnav.SelectDescendants(XPathNodeType.Element,false);while(xpNodeIter.MoveNext()){sCurrValues+=xpNodeIter.Current.Value+"~";}Ado.Net應用A的一些思考原則1.根據(jù)數(shù)據(jù)使用的方式來設計數(shù)據(jù)訪問層2.緩存數(shù)據(jù),避免不必要的操作3.使用服務帳戶進行連接4.必要時申請,盡早釋放5.關閉可關閉的資源6.減少往返7.僅返回需要的數(shù)據(jù)8.選擇適當?shù)氖聞疹愋?.使用存儲過程Connection數(shù)據(jù)庫連接是一種共享資源,并且打開和關閉的開銷較大。A默認啟用了連接池機制,關閉連接不會真的關閉物理連接,而只是把連接放回到連接池中。因為池中共享的連接資源始終是有限的,如果在使用連接后不盡快關閉連接,那么就有可能導致申請連接的線程被阻塞住,影響整個系統(tǒng)的性能表現(xiàn)。在方法中打開和關閉連接這個原則有幾層含義:1.主要目的是為了做到必要時申請和盡早釋放2.不要在類的構造函數(shù)中打開連接、在析構函數(shù)中釋放連接。因為這將依賴于垃圾回收,而垃圾回收只受內(nèi)存影響,回收時機不定3.不要在方法之間傳遞連接,這往往導致連接保持打開的時間過長這里強調(diào)一下在方法之間傳遞連接的危害:曾經(jīng)在壓力測試中遇到過一個測試案例,當增大用戶數(shù)的時候,這個案例要比別的案例早很久就用掉連接池中的所有連接。經(jīng)分析,就是因為A方法把一個打開的連接傳遞到了B方法,而B方法又調(diào)用了一個自行打開和關閉連接的C方法。在A方法的整個運行期間,它至少需要占用兩條連接才能夠成功工作,并且其中的一條連接占用時間還特別長,所以造成連接池資源緊張,影響了整個系統(tǒng)的可伸縮性!顯式關閉連接Connection對象本身在垃圾回收時可以被關閉,而依賴垃圾回收是很不好的策略。推薦使用using語句顯式關閉連接,如下例:using(SqlConnectionconn=newSqlConnection(connString)){ conn.Open(); }//Disposeisautomaticallycalledontheconnvariablehere確保連接池啟用A是為每個不同的連接串建立連接池,因此應該確保連接串不會出現(xiàn)與具體用戶相關的信息。另外,要注意連接串是大小寫敏感的。不要緩存連接例如,把連接緩存到Session或Application中。在啟用連接池的情況下,這種做法沒有任何意義。Command使用ExecuteScalar和ExecuteNonQuery如果想返回像Count(*)、Sum(Price)或Avg(Quantity)那樣的單值,可以使用ExecuteScalar方法。ExecuteScalar返回第一行第一列的值,將結果集作為標量值返回。因為單獨一步就能完成,所以ExecuteScalar不僅簡化了代碼,還提高了性能。使用不返回行的SQL語句時,例如修改數(shù)據(jù)(INSERT、UPDATE或DELETE)或僅返回輸出參數(shù)或返回值,請使用ExecuteNonQuery。這避免了用于創(chuàng)建空DataReader的任何不必要處理。使用Prepare當需要重復執(zhí)行同一SQL語句多次,可考慮使用Prepare方法提升效率。需要注意的是,如果只是執(zhí)行一次或兩次,則完全沒有必要。例如:cmd.CommandText="insertintoTable1(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();使用綁定變量★SQL語句需要先被編譯成執(zhí)行計劃,然后再執(zhí)行。如果使用綁定變量的方式,那么這個執(zhí)行計劃就可以被后續(xù)執(zhí)行的SQL語句所復用。而如果直接把參數(shù)合并到了SQL語句中,由于參數(shù)值千變?nèi)f化,執(zhí)行計劃就難以被復用了。例如上面Prepare一節(jié)給出的示例,如果把參數(shù)值直接寫到insert語句中,那么上面的四次調(diào)用將需要編譯四次執(zhí)行計劃。為避免這種情況造成性能損失,要求一律使用綁定變量方式。DataReaderDataReader最適合于訪問只讀的單向數(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顯式關閉DataReader與連接類似,也需要顯式關閉DataReader。另外,如果與DataReader關聯(lián)的Connection僅為DataReader服務的話,可考慮使用Command對象的ExecuteReader(CommandBehavior.CloseConnection)方式。這可以保證當DataReader關閉時,同時自動關閉Connection。用索引號訪問代替名稱索引號訪問屬性從Row中訪問某列屬性,使用索引號的方式比使用名稱方式有細微提高。如果會被頻繁調(diào)用,例如在循環(huán)中,那么可考慮此類優(yōu)化。示例如下:cmd.CommandText="selectCol1,Col2fromTable1";SqlDataReaderdr=cmd.ExecuteReader();intcol1=dr.GetOrdinal("Col1");intcol2=dr.GetOrdinal("Col2");while(dr.Read()){Console.WriteLine(dr[col1]+"_"+dr[col2]); }使用類型化方法訪問屬性從Row中訪問某列屬性,用GetString、GetInt32這種顯式指明類型的方法,其效率較通用的GetValue方法有細微提高,因為不需要做類型轉換。使用多數(shù)據(jù)集部分場景可以考慮一次返回多數(shù)據(jù)集來降低網(wǎng)絡交互次數(shù),提升效率。示例如下:cmd.CommandText="StoredProcedureName";//Thestoredprocedurereturnsmultipleresultsets.SqlDataReaderdr=cmd.ExecuteReader();while(dr.read())//readfirstresultsetdr.NextResult();while(dr.read())//DataSet利用索引加快查找行的效率如果需要反復查找行,建議增加索引。有兩種方式:1.設置DataTable的PrimaryKey適用于按PrimaryKey查找行的情況。注意此時應調(diào)用DataTable.Rows.Find方法,一般慣用的Select方法不能利用索引。2.使用DataView適用于按Non-PrimaryKey查找行的情況??蔀镈ataTable創(chuàng)建一個DataView,并通過SortOrder參數(shù)指示建立索引。此后使用Find或FindRows查找行。在C++中封裝的概念是把一個對象的外觀接口同實際工作方式(實現(xiàn))分離開來,但是C++的封裝是不完全的,編譯器必須知道一個對象的所有部分的聲明,以便創(chuàng)建和管理它。我們可以想象一種只需聲明一個對象的公共接口部分的編程語言,而將私有的實現(xiàn)部分隱藏起來。C++在編譯期間要盡可能多地做靜態(tài)類型檢查。這意味著盡早捕獲錯誤,也意味著程序具有更高的效率。然而這對私有的實現(xiàn)部分來說帶來兩個影響:一是即使程序員不能輕易地訪問實現(xiàn)部分,但他可以看到它;二是造成一些不必要的重復編譯。然而C++并沒有將這個原則應用到二進制層次上,這是因為C++的類既是描述了一個接口同時也描述了實現(xiàn)的過程,示例如下:classCMyString{private:constintm_cch;char*m_psz;public:CMyString(constchar*psz);~CMyString();intLength()const;intIndex(constchar*psz)const;}CMyStirng對外過多的暴露了內(nèi)存布局實現(xiàn)的細節(jié),這些信息過度的依賴于這些成員變量的大小和順序,從而導致了客戶過度依賴于可執(zhí)行代碼之間的二進制耦合關系,這樣的接口不利于跨語言跨平臺的軟件開發(fā)和移植。Handle-Body模式解決這個問題的技術有一種叫句柄類(handleclasses)。有關實現(xiàn)的任何東西都消失了,只剩一個單一的指針“m_pThis”。該指針指向一個結構,該結構的定義與其所有的成員函數(shù)的定義都出現(xiàn)在實現(xiàn)文件中。這樣,只要接口部分不改變,頭文件就不需變動。而實現(xiàn)部分可以按需要任意更動,完成后只要對實現(xiàn)文件進行重新編譯,然后再連接到項目中。下面是這項技術的簡單例子。頭文件中只包含公共的接口和一個簡單的沒有完全指定的類指針。classCMyStringHandle{private:classCMyString;CMyString*m_pThis;public:CMyStringHandle(constchar*psz);~CMyStringHandle();intLength()const;intIndex(constchar*psz)const;};CMyStringHandle::CMyStringHandle(constchar*psz):m_pThis(newCMyString(psz));{ }CMyStringHandle::~CMyStringHandle(){ deletem_pThis; }intCMyStringHandle::Length(){ returnm_pThis->Length(); }intCMyStringHandle::Index(constchar*psz){ returnm_pThis->Index(psz); }這是所有客戶程序員都能看到的。classCMyString; 是一個沒有完全指定的類型說明或類聲明(一個類的定義包含類的主體)。它告訴編譯器,CMyString是一個結構的名字,但沒有提供有關該結構的任何東西。這對產(chǎn)生一個指向結構的指針來說已經(jīng)足夠了。但我們在提供一個結構的主體部分之前不能創(chuàng)建一個對象。在這種技術里,包含具體實現(xiàn)的結構主體被隱藏在實現(xiàn)文件中。在設計模式中,這就叫做Handle-Body模式,Handle-Body只含有一個實體指針,服務的數(shù)據(jù)成員永遠被封閉在服務系統(tǒng)中。Handle-Body的布局結構永遠不會隨著實現(xiàn)類數(shù)據(jù)成員的加入或者刪除或者修改而導致Handle-Body的修改,即Handle-Body協(xié)議不依賴于C++實現(xiàn)類的任何細節(jié)。這就有效的對用戶的編譯器隱藏了這些細節(jié),用戶在使用對這項技術時候,Handle-Body接口成了它唯一的入口。然而Handle-Body模式也有自己的弱點:1、接口類必須把每一個方法調(diào)用顯示的傳遞給實現(xiàn)類,這在一個只有一個構造和一個析構的類來說顯然不構成負擔,但是如果一個龐大的類庫,它有上百上千個方法時候,光是編寫這些方法傳遞就有可能非常冗長,這也增加了出錯的可能性。2、對于關注于性能的應用每一個方法都得有兩層的函數(shù)調(diào)用,嵌套的開銷也不理想3、由于句柄的存在,依然存在編譯連接器兼容性問題。抽象接口使用了“接口與實現(xiàn)的分離”技術的Handle-Body解決了編譯器/鏈接器的大部分問題,而C++面向對象編程中的抽象接口同樣是運用了“接口與實現(xiàn)分離”的思想,而采用抽象接口對于解決這類問題是一個極其完美的解決方案。1、抽象接口的語言描述:classIMyString{virtualintLength()const=0;//這表示是一個純虛函數(shù),具有純虛函數(shù)的接口virtualintIndex(constchar*psz)const=0;};2、抽象接口的內(nèi)存結構:抽象接口采用虛函數(shù)表來調(diào)用成員方法。3、抽象接口的實現(xiàn)代碼:接口:classIMyString實現(xiàn):classCMyString:publicIMyString{private:constintm_cch;char*m_psz;public:CMyString(constchar*psz);virtual~CMyString();intLength()const;intIndex(constchar*psz)const;}從上面采用抽象接口的實例來看,抽象接口解決了Handle-Body所遺留下來的全部缺陷。抽象接口的一個典型應用:抽象工廠(AbstractFactroy)多繼承與菱形缺陷、this跳轉等多重繼承
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
- 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 2025年代理商品產(chǎn)品維修協(xié)議
- 2025年分期付款服裝鞋包購買合同
- 2025年專業(yè)的人才篩選與匹配協(xié)議書
- 2025年水土保持監(jiān)測技術咨詢與植被恢復合同3篇
- 二零二五年插畫師兼職聘用合同樣本3篇
- 二零二五年度數(shù)字經(jīng)濟投資合伙人協(xié)議書4篇
- 二零二五版茶葉品牌授權合作協(xié)議范本(市場拓展)3篇
- 二零二五年度風力發(fā)電機組安裝工程風力保險合同3篇
- 二零二五年鋼結構建筑裝修工程合同規(guī)范6篇
- 二零二五年集裝箱房租賃合同糾紛調(diào)解及仲裁協(xié)議3篇
- 2024-2025學年人教版初中物理九年級全一冊《電與磁》單元測試卷(原卷版)
- 江蘇單招英語考綱詞匯
- 礦山隱蔽致災普查治理報告
- 2024年事業(yè)單位財務工作計劃例文(6篇)
- PDCA循環(huán)提高護士培訓率
- 2024年工程咨詢服務承諾書
- 青桔單車保險合同條例
- 車輛使用不過戶免責協(xié)議書范文范本
- 《獅子王》電影賞析
- 2023-2024學年天津市部分區(qū)九年級(上)期末物理試卷
- DB13-T 5673-2023 公路自愈合瀝青混合料薄層超薄層罩面施工技術規(guī)范
評論
0/150
提交評論