也談string.Join和StringBuilder的性能比較


前幾天在園子里面看到一篇講StringBuilder性能的文章( https://www.cnblogs.com/wanghao72214/p/15571181.html )。文章里面給出了一個測試用例,比較StringBuilder.AppendJoin和String.Join的性能。根據該測試結果,“對於這個操作,這兩種方法的速度很接近,但 StringBuilder.AppendJoin 使用的內存明顯較少”。據此,該文言之鑿鑿地指出,應該使用“StringBuilder.AppendJoin 而不是 String.Join”。

事實果真如此嗎?

搜索一下就知道,StringBuilder采用的是先預分配緩沖區,然后將要連接的字符串直接復制到緩沖區的做法。這個做法確實高效,避免了中間結果帶來的時間消耗和內存占用。

那么,string.Join真的那么不堪嗎?

首先看看string.Join的代碼:

public static string Join(string separator, params string[] value)
{
    if (value == null)
    {
        throw new ArgumentNullException("value");
    }
    return string.Join(separator, value, 0, value.Length);
}

public unsafe static string Join(string separator, string[] value, int startIndex, int count)
{
    if (value == null)
    {
        throw new ArgumentNullException("value");
    }
    if (startIndex < 0)
    {
        throw new ArgumentOutOfRangeException("startIndex", Environment.GetResourceString("ArgumentOutOfRange_StartIndex"));
    }
    if (count < 0)
    {
        throw new ArgumentOutOfRangeException("count", Environment.GetResourceString("ArgumentOutOfRange_NegativeCount"));
    }
    if (startIndex > value.Length - count)
    {
        throw new ArgumentOutOfRangeException("startIndex", Environment.GetResourceString("ArgumentOutOfRange_IndexCountBuffer"));
    }
    if (separator == null)
    {
        separator = string.Empty;
    }
    if (count == 0)
    {
        return string.Empty;
    }
    int num = 0;
    int num2 = startIndex + count - 1;
    for (int i = startIndex; i <= num2; i++)
    {
        if (value[i] != null)
        {
            num += value[i].Length;
        }
    }
    num += (count - 1) * separator.Length;
    if (num < 0 || num + 1 < 0)
    {
        throw new OutOfMemoryException();
    }
    if (num == 0)
    {
        return string.Empty;
    }
    string text = string.FastAllocateString(num);
    fixed (char* ptr = &text.m_firstChar)
    {
        UnSafeCharBuffer unSafeCharBuffer = new UnSafeCharBuffer(ptr, num);
        unSafeCharBuffer.AppendString(value[startIndex]);
        for (int j = startIndex + 1; j <= num2; j++)
        {
            unSafeCharBuffer.AppendString(separator);
            unSafeCharBuffer.AppendString(value[j]);
        }
    }
    return text;
}
View Code

 可以看到,string.Join的做法是先計算最終結果的大小,然后調用string.FastAllocateString分配空間,最后將數據直接復制到分配的緩沖區。很顯然,這一過程和StringBuilder如出一轍。

但是測試結果畢竟擺在那里,那么問題在哪里呢?

看看該文的測試用例:

[Benchmark]
public string UsingStringJoin() {
            var list = new List < string > {
                        "A",
                        "B", "C", "D", "E"
            };
            var stringBuilder = new StringBuilder();
            for (int i = 0; i < 10000; i++) {
                        stringBuilder.Append(string.Join(' ', list));
            }
            return stringBuilder.ToString();
}
[Benchmark]
public string UsingAppendJoin() {
            var list = new List < string > {
                        "A",
                        "B", "C", "D", "E"
            };
            var stringBuilder = new StringBuilder();
            for (int i = 0; i < 10000; i++) {
                        stringBuilder.AppendJoin(' ', list);
            }
            return stringBuilder.ToString();
}
View Code

問題就在下面的一句:

stringBuilder.Append(string.Join(' ', list));

這句代碼實際上是先用string.Join把list拼好,再調用stringBuilder.Append把string.Join的結果拼接起來。這樣,string.Join分配一次內存,stringBuilder再分配一次內存,內存占用怎能不大?

當然,沒碼沒真相,得拿編譯后的IL說話。所以,根據這個用法寫段測試代碼:

private void BtnStartClick(object sender, EventArgs e)
{
    string[] dummy = new string[]
    {
        "zfsdfsd",
        "sdfsdf"
    };
    StringBuilder sb = new StringBuilder();
    sb.Append(string.Join(",", dummy));
    string s = sb.ToString();
    Console.WriteLine(s);
}
View Code

看看IL:

 1 .method private hidebysig 
 2     instance void BtnStartClick (
 3         object sender,
 4         class [mscorlib]System.EventArgs e
 5     ) cil managed 
 6 {
 7     // Header Size: 12 bytes
 8     // Code Size: 65 (0x41) bytes
 9     // LocalVarSig Token: 0x11000004 RID: 4
10     .maxstack 3
11     .locals init (
12         [0] string[] dummy,
13         [1] class [mscorlib]System.Text.StringBuilder sb,
14         [2] string s,
15         [3] string[] CS$0$0000
16     )
17 
18     /* (34,3)-(34,4) d:\Work_Private\IoT\ClientSimulator\MainForm.cs */
19     /* 0x00000340 00           */ IL_0000: nop
20     /* (35,4)-(35,52) d:\Work_Private\IoT\ClientSimulator\MainForm.cs */
21     /* 0x00000341 18           */ IL_0001: ldc.i4.2
22     /* 0x00000342 8D1D000001   */ IL_0002: newarr    [mscorlib]System.String
23     /* 0x00000347 0D           */ IL_0007: stloc.3
24     /* 0x00000348 09           */ IL_0008: ldloc.3
25     /* 0x00000349 16           */ IL_0009: ldc.i4.0
26     /* 0x0000034A 7201000070   */ IL_000A: ldstr     "zfsdfsd"
27     /* 0x0000034F A2           */ IL_000F: stelem.ref
28     /* 0x00000350 09           */ IL_0010: ldloc.3
29     /* 0x00000351 17           */ IL_0011: ldc.i4.1
30     /* 0x00000352 7211000070   */ IL_0012: ldstr     "sdfsdf"
31     /* 0x00000357 A2           */ IL_0017: stelem.ref
32     /* 0x00000358 09           */ IL_0018: ldloc.3
33     /* 0x00000359 0A           */ IL_0019: stloc.0
34     /* (37,4)-(37,41) d:\Work_Private\IoT\ClientSimulator\MainForm.cs */
35     /* 0x0000035A 731600000A   */ IL_001A: newobj    instance void [mscorlib]System.Text.StringBuilder::.ctor()
36     /* 0x0000035F 0B           */ IL_001F: stloc.1
37     /* (38,4)-(38,38) d:\Work_Private\IoT\ClientSimulator\MainForm.cs */
38     /* 0x00000360 07           */ IL_0020: ldloc.1
39     /* 0x00000361 721F000070   */ IL_0021: ldstr     ","
40     /* 0x00000366 06           */ IL_0026: ldloc.0
41     /* 0x00000367 281700000A   */ IL_0027: call      string [mscorlib]System.String::Join(string, string[])
42     /* 0x0000036C 6F1800000A   */ IL_002C: callvirt  instance class [mscorlib]System.Text.StringBuilder [mscorlib]System.Text.StringBuilder::Append(string)
43     /* 0x00000371 26           */ IL_0031: pop
44     /* (40,4)-(40,27) d:\Work_Private\IoT\ClientSimulator\MainForm.cs */
45     /* 0x00000372 07           */ IL_0032: ldloc.1
46     /* 0x00000373 6F1900000A   */ IL_0033: callvirt  instance string [mscorlib]System.Object::ToString()
47     /* 0x00000378 0C           */ IL_0038: stloc.2
48     /* (42,4)-(42,25) d:\Work_Private\IoT\ClientSimulator\MainForm.cs */
49     /* 0x00000379 08           */ IL_0039: ldloc.2
50     /* 0x0000037A 281A00000A   */ IL_003A: call      void [mscorlib]System.Console::WriteLine(string)
51     /* 0x0000037F 00           */ IL_003F: nop
52     /* (45,3)-(45,4) d:\Work_Private\IoT\ClientSimulator\MainForm.cs */
53     /* 0x00000380 2A           */ IL_0040: ret
54 } // end of method MainForm::BtnStartClick
View Code

從第41和42行可以清楚看到,代碼先調用了String.Join,然后是StringBuilder.Append.

所以事情很清楚了。錯誤的代碼得出了不符合本意的測試結果,根據這個結果得到的結論自然也是錯誤的。

實際上,根據MS的文檔,“修改 StringBuilder 時,除非達到容量,否則對象不會為自己重新分配空間。 當達到容量時,將自動分配新的空間且容量翻倍。”,可以看出,在邊界情況下,使用StringBuilder耗費的空間反而比Join要大。當然,考慮到內存對齊的因素,Join也會有部分內存浪費,但這實在是微不足道的。

那么,應該使用StringBuilder還是Join呢?

很簡單,按照具體情況決定。如果要拼接的是現成的字符串數組,自然應該用Join。否則的話,還是用StringBuilder省事點。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM