重談字串連線效能（上）效能評測

看到這個標題是不是覺得很奇怪呢？字串連線的效能，這個話題已經被談了一遍又一遍，一次又一次，似乎已成定論，這又有什麼好談的呢？不過說來奇怪，根據我的實驗結果在網上進行搜尋，卻找不到答案。因此，我現在和大家一起重新再作一次實驗並觀察結果。在文章最後我也會給出完整的**，您可以自由地執行，修改，嘗試，我們再一起進行交流。

說起字串拼接，最簡單的方式便是使用最普通的連線操作「+」，以及stringbuilder了。為此，我們準備一些測試**：

private static readonly string str = "0123456789";
private static string normalconcat(int count)
private static string stringbuilder(int count)

兩個方法都是將乙個長度為10的字串連線n次，形成乙個很長的字串。相信看到這兩段**您在心裡可能已經有所答案了，不過別急，我們再準備一段**。一直說stringbuilder在連線字串的時候效能高，那是為什麼呢？我們如果翻看《clr via c#》，就會發現書中告訴我們說，在stringbuilder內部其實維護了乙個類似於字元陣列的結構，在不斷新增字串的過程中，這個陣列會在需要的時候將容量加倍——這不就是list的行為方式嗎？那麼我們自己來寫乙個charlistbuilder，也一起和stringbuilder比較一下效能：

public class 
charlistbuilder
public string tostring()
}private static string charlistbuilder(int count)

開始實驗：

codetimer.initialize();
for (int i = 2; i <= 1024; i *= 2)
)", i),
10000,
() => normalconcat(i));
codetimer.time(
string.format("stringbuilder ()", i),
10000,
() => stringbuilder(i));
codetimer.time(
string.format("charlistbuilder ()", i),
10000,
() => charlistbuilder(i));
}

結果如下：

將結果繪製為圖表：

我在網際網路上找尋了半天，似乎各個實驗做到這裡就得到結論了，那就是：在字串數量多的情況下，stringbuilder效能比普通連線操作來的好。其原因便是「普通連線操作實際上使用了string.concat方法，每次都會生成新的字串」。但是，如果您觀察string.concat方法，就會發現其實它接受的引數是乙個string陣列——那麼，如果我們把要連線的字串放在乙個陣列裡，一次交給string.concat進行連線，效能又會怎麼樣？不妨一試：

private static string stringconcat(int count)

但這種做法有個前提，就是我們必須事先知道有多少個字串才能建立這樣乙個陣列，而對於數量未知的情況就不太好辦了。不過也沒有關係，我們可以用list先將所有字串儲存起來：

public class 
stringlistbuilder
public string tostring()
}private static string stringlistbuilder(int count)

再把這兩種新的做法和stringbuilder進行比較（第一次的其他兩種做法效能不堪一擊，直接淘汰）：

從數量級上看，這次的比較似乎還算「勢均力敵」。不過還是繪製成圖表看起來比較清楚：

重談字串連線效能（上） 效能評測

重談字串連線效能（上） 效能評測

字串連線

字串連線

相關推薦

重談字串連線效能（上）效能評測

重談字串連線效能（上）效能評測