重谈字符串连接性能（上）：性能评测

看到这个标题是不是觉得很奇怪呢？字符串连接的性能，这个话题已经被谈了一遍又一遍，一次又一次，似乎已成定论，这又有什么好谈的呢？不过说来奇怪，根据我的实验结果在网上进行搜索，却找不到答案。因此，我现在和大家一起重新再作一次实验并观察结果。在文章最后我也会给出完整的代码，您可以自由地运行，修改，尝试，我们再一起进行交流。

说起字符串拼接，最简单的方式便是使用最普通的连接操作“+”，以及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的性能吗？

相关文章

• 重谈字符串连接性能（上）：性能评测
• 重谈字符串连接性能（中）：细节实现
• 重谈字符串连接性能（下）：分析优化