重谈字符串连接性能（上）：性能评测
2009-11-26 01:12 by 老赵, 15229 visits看到这个标题是不是觉得很奇怪呢？字符串连接的性能，这个话题已经被谈了一遍又一遍，一次又一次，似乎已成定论，这又有什么好谈的呢？不过说来奇怪，根据我的实验结果在网上进行搜索，却找不到答案。因此，我现在和大家一起重新再作一次实验并观察结果。在文章最后我也会给出完整的代码，您可以自由地运行，修改，尝试，我们再一起进行交流。
说起字符串拼接，最简单的方式便是使用最普通的连接操作“+”，以及StringBuilder了。为此，我们准备一些测试代码：
private static readonly string STR = "0123456789"; private static string NormalConcat(int count) { var result = ""; for (int i = 0; i < count; i++) result += STR; return result; } private static string StringBuilder(int count) { var builder = new StringBuilder(); for (int i = 0; i < count; i++) builder.Append(STR); return builder.ToString(); }
两个方法都是将一个长度为10的字符串连接n次，形成一个很长的字符串。相信看到这两段代码您在心里可能已经有所答案了，不过别急，我们再准备一段代码。一直说StringBuilder在连接字符串的时候性能高，那是为什么呢？我们如果翻看《CLR via C#》，就会发现书中告诉我们说，在StringBuilder内部其实维护了一个类似于字符数组的结构，在不断添加字符串的过程中，这个数组会在需要的时候将容量加倍——这不就是List<T>的行为方式吗？那么我们自己来写一个CharListBuilder，也一起和StringBuilder比较一下性能：
public class CharListBuilder { private List<char> m_list = new List<char>(); public CharListBuilder Append(string s) { this.m_list.AddRange(s); return this; } public string ToString() { return new String(this.m_list.ToArray()); } } private static string CharListBuilder(int count) { var builder = new CharListBuilder(); for (int i = 0; i < count; i++) builder.Append(STR); return builder.ToString(); }
开始实验：
CodeTimer.Initialize(); for (int i = 2; i <= 1024; i *= 2) { CodeTimer.Time( String.Format("Normal Concat ({0})", i), 10000, () => NormalConcat(i)); CodeTimer.Time( String.Format("StringBuilder ({0})", i), 10000, () => StringBuilder(i)); CodeTimer.Time( String.Format("CharListBuilder ({0})", i), 10000, () => CharListBuilder(i)); }
结果如下：
将结果绘制为图表：
由于字符串的普通连接操作和StringBuilder相比差距越来越大，当使用1024个字符串进行连接时两者已经没有任何可比性了，因此这幅图表只取了前7个阶段，也就是最多到128个字符串相连接。从结果中我们可以得到以下三个结论：
- 对于字符串数量比较少的情况（从数据上来看大约是5-6个），StringBuilder的性能并不比普通连接操作来的快。因此，在任何地方都使用StringBuilder是不恰当的做法。
- 我们的CharListBuilder虽然“模拟”了StringBuilder的情况，但还是慢了许多。说明StringBuilder的内部实现并非想象中那么简单。
- CharListBuilder虽然比StringBuilder慢得多，但是在字符串数量多的情况下还是遥遥领先普通的字符串连接操作，说明不断生成新字符串的做法的确是性能杀手。
我在互联网上找寻了半天，似乎各个实验做到这里就得到结论了，那就是：在字符串数量多的情况下，StringBuilder性能比普通连接操作来的好。其原因便是“普通连接操作实际上使用了String.Concat方法，每次都会生成新的字符串”。但是，如果您观察String.Concat方法，就会发现其实它接受的参数是一个String数组——那么，如果我们把要连接的字符串放在一个数组里，一次交给String.Concat进行连接，性能又会怎么样？不妨一试：
private static string StringConcat(int count) { var array = new string[count]; for (int i = 0; i < count; i++) array[i] = STR; return String.Concat(array); }
但这种做法有个前提，就是我们必须事先知道有多少个字符串才能创建这样一个数组，而对于数量未知的情况就不太好办了。不过也没有关系，我们可以用List<string>先将所有字符串保存起来：
public class StringListBuilder { private List<string> m_list = new List<string>(); public StringListBuilder Append(string s) { this.m_list.Add(s); return this; } public string ToString() { return String.Concat(this.m_list.ToArray()); } } private static string StringListBuilder(int count) { var builder = new StringListBuilder(); for (int i = 0; i < count; i++) builder.Append(STR); return builder.ToString(); }
再把这两种新的做法和StringBuilder进行比较（第一次的其他两种做法性能不堪一击，直接淘汰）：
从数量级上看，这次的比较似乎还算“势均力敌”。不过还是绘制成图表看起来比较清楚：
如果用一句话来概括的话，那就是：“StringBuilder以明显了劣势垫底”。不过说实话，这个结果并没有出乎我的意料之外，事实上这本就是我进行这次实验的原因——我始终想不明白，StringBuilder的性能为什么会比String.Concat要高（因为互联网上到处都在“追捧”StringBuilder）。幸好，最终的结果证明了我的猜想：在字符串数量确定的情况下，String.Concat的性能要高于StringBuilder，而且其实字符串数量越多，差距越明显。
但这又是为什么呢？那么我们就把以下几个疑问留到下一次来解决吧：
- 为什么StringBuilder性能比CharListBuilder要高？
- 为什么String.Concat性能比StringBuilder要高？
- 有什么办法可以改进StringBuilder的性能吗？
相关文章
- 重谈字符串连接性能（上）：性能评测
- 重谈字符串连接性能（中）：细节实现
- 重谈字符串连接性能（下）：分析优化
有些朋友是不是看不到表格和图片啊？那么看这里吧，我把文章内容截了一幅图。
http://cid-fba4447598b1d752.skydrive.live.com/self.aspx/Public/string-concat-perf-1.zip
不过，还是尽快想办法直接看到吧，我不会长期截图的，而且其实看到“看不到的东西”，现在也应该是必备技能了……