介紹C#字符串的性能
簡(jiǎn)介
你在代碼中處理C#字符串的方法可能會(huì)對(duì)性能產(chǎn)生令人吃驚的影響。程序中需要考慮兩個(gè)由于使用字符串而產(chǎn)生的問(wèn)題：臨時(shí)字符串變量的使用和字符串連接。
背景知識(shí)
1.String是引用類型，在堆上分配內(nèi)存。
2.String運(yùn)算時(shí)會(huì)產(chǎn)生一個(gè)新的實(shí)例。當(dāng)看到 myString.ToUpper() 時(shí)，我經(jīng)常都會(huì)忘記它并不是改變 myString 的內(nèi)容而是返回一整個(gè)全新的字符串（這是由于C# 字符串是不可變的）。
3.String 對(duì)象一旦生成不可改變（Immutable)。
4.定義相等運(yùn)算符（== 和 !=）是為了比較 String 對(duì)象（而不是引用）的值。
String Comparison and Temporary String Creation
下面的例程是一個(gè)蹩腳的非大小寫敏感的字符串比較。用于比較的例程的代碼是：
- static bool BadCompare(string stringA, string stringB)
- {
- return (stringA.ToUpper() == stringB.ToUpper());
- }
對(duì)于這段代碼，F(xiàn)xCop 給出如下的建議：
這項(xiàng)建議的意思是每次對(duì) ToUpper() 的調(diào)用都會(huì)創(chuàng)造一個(gè)臨時(shí)字符串，而這個(gè)臨時(shí)字符串是由垃圾收集器來(lái)創(chuàng)建和管理的。這需要額外的時(shí)間和使用更多的內(nèi)存。 String.Compare 方法（相對(duì)來(lái)說(shuō)）更加高效。
String Concatenation inside a loop
***那對(duì)測(cè)試?yán)淘O(shè)想字符串的連接是在一個(gè)循環(huán)里面進(jìn)行的。
“蹩腳”的測(cè)試?yán)痰拇a如下：
- static string BadConcatenate(string [] items)
- {
- string strRet = string .Empty;
- foreach (string item in items)
- {
- strRet += item;
- }
- return strRet;
- }
當(dāng) FxCop 看到這段代碼，它就會(huì)很憤怒，甚至用紅色標(biāo)記這項(xiàng)被破的規(guī)條！ FxCop 這樣說(shuō)道：
“優(yōu)良”的測(cè)試?yán)痰拇a如下：
- 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 的用法的***例子。蹩腳的代碼的問(wèn)題是創(chuàng)建了過(guò)多的臨時(shí)字符串。由于字符串的不可變特性，連接操作符（+=）實(shí)際上用原來(lái)那兩個(gè)字符串來(lái)創(chuàng)建一個(gè)新的字符串，然后把原來(lái)的字符串實(shí)例指向這個(gè)新的字符串。
但是，依據(jù) nprof 來(lái)研究代碼性能，我們發(fā)現(xiàn)運(yùn)行 BadConcatenate 只需總執(zhí)行時(shí)間的 5.67% ，而 GoodConcatenate 則是 22.09% 。也就是說(shuō)：
使用 StringBuilder 耗費(fèi)的時(shí)間幾乎是簡(jiǎn)單的字符串連接的四倍！
為什么呢？
部分原因在于這個(gè)測(cè)試的設(shè)計(jì)——連接例程僅僅連接了十個(gè)簡(jiǎn)短的字符串。 StringBuilder 是一個(gè)比簡(jiǎn)單的不可變的字符串類更復(fù)雜的類，因此創(chuàng)建一個(gè) StringBuilder 比起進(jìn)行十個(gè)簡(jiǎn)單的字符串連接在性能上是昂貴很多的。
我重復(fù)地做不同數(shù)目的字符串連接的測(cè)試，并且發(fā)現(xiàn)以下結(jié)果：
結(jié)論
使用 String.Compare 方法進(jìn)行非大小寫敏感的C#字符串比較。這樣更快。而且代碼優(yōu)雅和簡(jiǎn)單。
僅當(dāng)你在一個(gè)循環(huán)里進(jìn)行超過(guò) 600 次的字符串連接時(shí)，使用 StringBuilder 來(lái)獲得更好的速度。這里需要提醒的是，你所處理的字符串的長(zhǎng)度也會(huì)影響最終的速度，同樣會(huì)影響垃圾收集器的效果，所以你應(yīng)該根據(jù)你實(shí)際的代碼具體問(wèn)題具體分析
使用 StringBuilder 來(lái)處理字符串的連接應(yīng)該是絕大多數(shù) .NET 開發(fā)人員的共識(shí)了。但你有否曾經(jīng)懷疑過(guò)這一經(jīng)驗(yàn)原則的適用性是否真如想象中那么廣泛呢？讀過(guò)本文后，或許你已經(jīng)意識(shí)到這是個(gè)適度的問(wèn)題。對(duì)小規(guī)模的字符串連接使用 StringBuilder 所帶來(lái)的改善根本不足以抵償因 StringBuilder 本身的復(fù)雜性所產(chǎn)生的開銷；只有當(dāng)連接規(guī)模達(dá)到臨界規(guī)模，兩者才能相互抵償從而達(dá)至平衡。
【編輯推薦】
