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