重谈字符串连接性能(上):性能评测

JerryXia 发表于 , 阅读 (754)

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

说起字符串拼接,最简单的方式便是使用最普通的连接操作“+”,以及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的性能并不比普通连接操作来的快。因此,<span>在任何地方都使用StringBuilder是不恰当的做法</span>。
  • 我们的CharListBuilder虽然“模拟”了StringBuilder的情况,但还是慢了许多。说明<span>StringBuilder的内部实现并非想象中那么简单</span>。
  • CharListBuilder虽然比StringBuilder慢得多,但是在字符串数量多的情况下还是遥遥领先普通的字符串连接操作,说明<span>不断生成新字符串的做法的确是性能杀手</span>。

我在互联网上找寻了半天,似乎各个实验做到这里就得到结论了,那就是:在字符串数量多的情况下,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的性能吗?

添加新评论