重谈字符串连接性能(上):性能评测
2009-11-26 01:12 by 老赵, 15359 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
不过,还是尽快想办法直接看到吧,我不会长期截图的,而且其实看到“看不到的东西”,现在也应该是必备技能了……