簡介

我們提供的服務(wù)有：成都網(wǎng)站制作、成都做網(wǎng)站、外貿(mào)營銷網(wǎng)站建設(shè)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、珠暉ssl等。為上千余家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的珠暉網(wǎng)站制作公司

你在代碼中處理C#字符串的方法可能會對性能產(chǎn)生令人吃驚的影響。程序中需要考慮兩個由于使用字符串而產(chǎn)生的問題：臨時字符串變量的使用和字符串連接。

背景知識

1.String是引用類型，在堆上分配內(nèi)存。

2.String運算時會產(chǎn)生一個新的實例。當看到 myString.ToUpper() 時，我經(jīng)常都會忘記它并不是改變 myString 的內(nèi)容而是返回一整個全新的字符串（這是由于C# 字符串是不可變的）。

3.String 對象一旦生成不可改變（Immutable)。

4.定義相等運算符（== 和 !=）是為了比較 String 對象（而不是引用）的值。

String Comparison and Temporary String Creation

下面的例程是一個蹩腳的非大小寫敏感的字符串比較。用于比較的例程的代碼是：

 
 
 
 

  
  
  
  
static bool BadCompare(string stringA, string stringB) 
  
  
  
  
{ 
  
  
  
  
    return (stringA.ToUpper() == stringB.ToUpper()); 
  
  
  
  
}
 
 
 
 

對于這段代碼，F(xiàn)xCop 給出如下的建議：

這項建議的意思是每次對 ToUpper() 的調(diào)用都會創(chuàng)造一個臨時字符串，而這個臨時字符串是由垃圾收集器來創(chuàng)建和管理的。這需要額外的時間和使用更多的內(nèi)存。 String.Compare 方法（相對來說）更加高效。

String Concatenation inside a loop

***那對測試例程設(shè)想字符串的連接是在一個循環(huán)里面進行的。

“蹩腳”的測試例程的代碼如下：

 
 
 
 

  
  
  
  
static string BadConcatenate(string [] items) 
  
  
  
  
{ 
  
  
  
  
    string strRet = string .Empty; 
  
  
  
  

  
  
  
  
    foreach (string item in items) 
  
  
  
  
    { 
  
  
  
  
        strRet += item; 
  
  
  
  
    } 
  
  
  
  

  
  
  
  
    return strRet; 
  
  
  
  
}
 
 
 
 

當 FxCop 看到這段代碼，它就會很憤怒，甚至用紅色標記這項被破的規(guī)條！ FxCop 這樣說道：

“優(yōu)良”的測試例程的代碼如下：

 
 
 
 

  
  
  
  
static string GoodConcatenate(string [] items) 
  
  
  
  
{ 
  
  
  
  
    System.Text.StringBuilder builder = new System.Text.StringBuilder(); 
  
  
  
  

  
  
  
  
    foreach (string item in items) 
  
  
  
  
    { 
  
  
  
  
        builder.Append(item); 
  
  
  
  
    } 
  
  
  
  

  
  
  
  
    return builder.ToString(); 
  
  
  
  
}
 
 
 
 

這段代碼幾乎被用作展示 System.Text.StringBuilder 的用法的***例子。蹩腳的代碼的問題是創(chuàng)建了過多的臨時字符串。由于字符串的不可變特性，連接操作符（+=）實際上用原來那兩個字符串來創(chuàng)建一個新的字符串，然后把原來的字符串實例指向這個新的字符串。

但是，依據(jù) nprof 來研究代碼性能，我們發(fā)現(xiàn)運行 BadConcatenate 只需總執(zhí)行時間的 5.67% ，而 GoodConcatenate 則是 22.09% 。也就是說：

使用 StringBuilder 耗費的時間幾乎是簡單的字符串連接的四倍！

為什么呢？

部分原因在于這個測試的設(shè)計——連接例程僅僅連接了十個簡短的字符串。 StringBuilder 是一個比簡單的不可變的字符串類更復(fù)雜的類，因此創(chuàng)建一個 StringBuilder 比起進行十個簡單的字符串連接在性能上是昂貴很多的。

我重復(fù)地做不同數(shù)目的字符串連接的測試，并且發(fā)現(xiàn)以下結(jié)果：

結(jié)論

使用 String.Compare 方法進行非大小寫敏感的C#字符串比較。這樣更快。而且代碼優(yōu)雅和簡單。

僅當你在一個循環(huán)里進行超過 600 次的字符串連接時，使用 StringBuilder 來獲得更好的速度。這里需要提醒的是，你所處理的字符串的長度也會影響最終的速度，同樣會影響垃圾收集器的效果，所以你應(yīng)該根據(jù)你實際的代碼具體問題具體分析

使用 StringBuilder 來處理字符串的連接應(yīng)該是絕大多數(shù) .NET 開發(fā)人員的共識了。但你有否曾經(jīng)懷疑過這一經(jīng)驗原則的適用性是否真如想象中那么廣泛呢？讀過本文后，或許你已經(jīng)意識到這是個適度的問題。對小規(guī)模的字符串連接使用 StringBuilder 所帶來的改善根本不足以抵償因 StringBuilder 本身的復(fù)雜性所產(chǎn)生的開銷；只有當連接規(guī)模達到臨界規(guī)模，兩者才能相互抵償從而達至平衡。

文章名稱：介紹C#字符串的性能
當前路徑：http://uogjgqi.cn/article/cdsjjpo.html