重谈字符串连接性能（下）：分析优化
2009-12-23 14:03 by 老赵, 9264 visits经过之间的性能比较，我们得知StringBuilder的性能并非时时最优，再经过实现分析，我们大致了解了StringBuilder的实现方式。虽然在此之前，大家也基本已经了解StringBuilder的实现原理，也有不少朋友指出了它性能缺陷的原因。不过“严谨”起见，寻找性能问题的方式应该是进行Profiling，然后找出性能关键再进行优化——而不是纯粹进行“阅读”这种静态分析方式。
那么，假设我们还是使用原来的方式使用StringBuilder连接字符串：
static void Main() { for (int i = 0; i < 100 * 100 * 20; i++) StringBuilder(1024); } private static readonly string STR = "0123456789"; private static string StringBuilder(int count) { var builder = new StringBuilder(); for (int i = 0; i < count; i++) builder.Append(STR); return builder.ToString(); }
我们对这段代码进行Profiling，便可以得到这样的结果：
从结果上可以看出，几乎所有时间都是消耗在Append操作上的（这是废话）。而在Append方法中，AppendInPlace和GetNewString方法都占用了较多的比例。从上次的代码分析中我们知道，AppendInPlace方法是将新的字符串复制到原字符序列（也就是那个“容器”）的后面，而GetNewString的作用便是创建一个新的，容量加倍字符串（容器）——它的主要消耗都在GetStringForStringBuilder方法上。
AppendInPlace的作用是复制字符串，消耗无法节省下来。但是，我们可以尽可能避免GetNewString的开销，只要减少“创建新容器”的次数即可。这意味着我们可以在一开始指定容量更大的StringBuilder。于是乎，我们尝试将StringBuilder的使用改写为如下形式：
private static string NewStringBuilder(int count) { var builder = new StringBuilder(count * STR.Length); for (int i = 0; i < count; i++) builder.Append(STR); return builder.ToString(); }
再次进行Profiling，结果如下：
由于我们一下子提供了足够的容量，因此在NewStringBuilder方法中一次“扩容”都不需要，因此也就不会调用GetNewString方法了。从上图中可以看出，此时AppendInPlace方法占用的比例增加了。与此对应的是StringBuilder的构造函数开销也增大了——因为需要一下子开辟较多的空间。由于总时间消耗地少，因此采样总数也比之前有所减少——这些结果都符合我们的推测。
于是我们将NewStringBuilder和之前的StringConcat以及StringListBuilder进行比较。公平起见，我也相应提高StringListBuilder中List<string>的容量，避免“扩容操作”：
class Program { static void Main() { CodeTimer.Initialize(); for (int i = 2; i <= 4096; i *= 2) { CodeTimer.Time( String.Format("StringBuilder ({0})", i), 10000, () => NewStringBuilder(i)); CodeTimer.Time( String.Format("String.Concat ({0})", i), 10000, () => StringConcat(i)); CodeTimer.Time( String.Format("StringListBuilder ({0})", i), 10000, () => StringListBuilder(i)); } } private static readonly string STR = "0123456789"; private static string NewStringBuilder(int count) { var builder = new StringBuilder(count * STR.Length); for (int i = 0; i < count; i++) builder.Append(STR); return builder.ToString(); } 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); } private static string StringListBuilder(int count) { var builder = new StringListBuilder(count); for (int i = 0; i < count; i++) builder.Append(STR); return builder.ToString(); } } public class StringListBuilder { private List<string> m_list; public StringListBuilder(int capacity) { this.m_list = new List<string>(capacity); } public StringListBuilder Append(string s) { this.m_list.Add(s); return this; } public string ToString() { return String.Concat(this.m_list.ToArray()); } }
结果如下：
绘制成图表：
终于，StringBuilder翻身了。由于避免了不断扩容，不断复制的过程，因此StringBuilder的性能已经成为三者中性能最高的作法。事实上，String.Concat高性能的原因，也正是事先知道了目标字符串的长度，实现了最高效的构造方法。而StringListBuilder，它比String.Concat需要进行更多List<string>和数组方面的维护，因此性能略低一些。
那么，经过了这三篇文章的比较和分析之后，我们是否可以知道哪种字符串连接方式性能最高呢？自然这需要根据情况而定：
- StringBuilder：如果能够确定目标字符串的最终长度，则可以使用StringBuilder。如果不能确定的话，也可以在一开始指定更大的容量，减少扩容的次数。
- String.Concat：如果不能确定最终长度，但是能够确定字符串的个数（如这个场景），可以将它们放在一个数组中，并调用String.Concat进行连接。
- StringListBuilder：折衷方案，与String.Concat相比其优势在于无需确定字符串个数，与StringBuilder相比其优势在于“扩容”操作只需复制一些引用即可。
我的“重谈”之旅到此就告一段落了，您是否觉得哪里还意犹未尽呢？
相关文章
- 重谈字符串连接性能（上）：性能评测
- 重谈字符串连接性能（中）：细节实现
- 重谈字符串连接性能（下）：分析优化
看不见图片和表格的兄弟可以看这里：
http://cid-fba4447598b1d752.skydrive.live.com/self.aspx/Public/string-concat-perf-3.zip
不过最好还是能看到吧。