StringBuilder內(nèi)部是由多段char[]組成的半自動(dòng)鏈表，因此頻繁從中間修改StringBuilder，會(huì)將原本連續(xù)的內(nèi)存分隔為多段，從而影響讀取/遍歷性能。

連續(xù)內(nèi)存與不連續(xù)內(nèi)存的性能差，可能高達(dá)1600倍。

背景

用StringBuilder的用戶可能大都想用StringBuilder拼接html/json模板、組裝動(dòng)態(tài)SQL等正常操作。但在一些特殊場(chǎng)景中——如為某種編程語(yǔ)言寫語(yǔ)言服務(wù)，或者寫一個(gè)富文本編輯器時(shí)，StringBuilder依然也有用武之地，通過(guò)里面的Insert/Remove兩個(gè)方法來(lái)修改。

測(cè)試方法

Talk is cheap, show me the code:

int docLength = 10000;
void Main()
{
  (from power in Enumerable.Range (1, 16)
  let mutations = (int) Math.Pow (2, power)
  select new
  {
    mutations,
    PerformanceRatio = Math.Round (GetPerformanceRatio (docLength, mutations), 1)
  }).Dump();
}

float GetPerformanceRatio (int docLength, int mutations)
{
  var sb = new StringBuilder ("".PadRight (docLength));
  var before = GetPerformance (sb);
  FragmentStringBuilder (sb, mutations);
  var after = GetPerformance (sb);
  return (float) after.Ticks / before.Ticks;
}

void FragmentStringBuilder (StringBuilder sb, int mutations)
{
  var r = new Random(42);
  for (int i = 0; i < mutations; i++)
  {
    sb.Insert (r.Next (sb.Length), 'x');
    sb.Remove (r.Next (sb.Length), 1);
  }
}

TimeSpan GetPerformance (StringBuilder sb)
{
  var sw = Stopwatch.StartNew();
  long tot = 0;
  for (int i = 0; i < sb.Length; i++)
  {
    char c = sb[i];
    tot += (int) c;
  }
  sw.Stop();
  return sw.Elapsed;
}

關(guān)于這段代碼，請(qǐng)注意以下幾點(diǎn)：

• 通過(guò).PadRight(n)來(lái)直接創(chuàng)建長(zhǎng)度為n的空白字符串，可以用new string(' ', n)來(lái)代替；
• new Random(42)處，我指定了一個(gè)隨機(jī)因子，確保每次分隔后分隔的位置完全相同，有利于做對(duì)照組；
• 我分別對(duì)字符串進(jìn)行了2^1 ~ 2^16次修改，分別比較經(jīng)過(guò)這么多次修改之后的性能差異；
• 我使用sb[i]來(lái)逐一訪問(wèn)StringBuilder中的位置，使內(nèi)存不連續(xù)性更加突顯。

運(yùn)行結(jié)果

可見如果在StringBuilder中間進(jìn)行大量修改，其性能會(huì)急據(jù)下降，注意看32768次修改的情況下，遍歷時(shí)會(huì)產(chǎn)生高達(dá)1630.4倍的性能差！

解決方式

如果一定要用StringBuilder，可以考慮在修改一定次數(shù)后，重新創(chuàng)建一個(gè)新的StringBuilder，以使得訪問(wèn)時(shí)獲得最佳的內(nèi)存連續(xù)性，即可解決此問(wèn)題：

void FragmentStringBuilder (StringBuilder sb, int mutations)
{
  var r = new Random(42);
  for (int i = 0; i < mutations; i++)
  {
    sb.Insert (r.Next (sb.Length), 'x');
    sb.Remove (r.Next (sb.Length), 1);
    
    // 重點(diǎn)
    const int defragmentCount = 250;
    if (i % defragmentCount == defragmentCount - 1)
    {
      string buf = sb.ToString();
      sb.Clear();
      sb.Append(buf);
    }
  }
}

如上，每經(jīng)過(guò)250次修改，即將原StringBuilder刪除，然后重新創(chuàng)建一個(gè)新的StringBuilder，此時(shí)運(yùn)行效果如下：

可見，在幾乎所有情況下，受內(nèi)存不連續(xù)造成的訪問(wèn)性能問(wèn)題，解決——同時(shí)250可能是一個(gè)相對(duì)比較合理的數(shù)字，在插入性能與查詢/遍歷性能中，獲得平衡。

反思與總結(jié)

眾所周知，由于string的不可變性，拼接大量字符串時(shí)，會(huì)浪費(fèi)大量?jī)?nèi)存。但使用StringBuilder也需要了解它的結(jié)構(gòu)。

StringBuilder這樣做成鏈?zhǔn)降慕Y(jié)構(gòu)并非沒(méi)有原因，如果考慮插入性能，做成鏈?zhǔn)浇涌谑亲顑?yōu)秀的。但如果考慮查詢性能，鏈?zhǔn)浇Y(jié)構(gòu)就非常不利了，如果設(shè)計(jì)為非鏈?zhǔn)浇Y(jié)構(gòu)，從中間插入時(shí)，StringBuilder的內(nèi)存空間可能不夠，因此需要重新分配內(nèi)存，這樣相當(dāng)于將StringBuilder降格為string，因此完全喪失了StringBuilder適合做“頻繁插入”的優(yōu)勢(shì)。

本文說(shuō)的其實(shí)是一個(gè)非常特殊的例子，現(xiàn)實(shí)中除了語(yǔ)言服務(wù)、編輯器外，很少會(huì)需要這種即要頻繁插入快，也要頻繁修改快的場(chǎng)景。如果想簡(jiǎn)單點(diǎn)搞，用StringBuilder會(huì)是一個(gè)有條件合適的解決方案。更適合的解決方案當(dāng)然是專門的數(shù)據(jù)結(jié)構(gòu)——PieceTable，微軟在VSCode編輯器中，為了確保大文件編輯性能，使用了該數(shù)據(jù)結(jié)構(gòu)，取得了非常不錯(cuò)的成果，參考鏈接：Text Buffer Reimplementation。

到此這篇關(guān)于淺談StringBuilder內(nèi)存碎片對(duì)性能的影響的文章就介紹到這了,更多相關(guān)StringBuilder 內(nèi)存碎片內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論