字串池化，減少了三分之一的記憶體佔用

Newbe36524發表於2021-09-13
字串記憶體

字串池化，減少重複例項，記憶體降低，一切就是這樣的輕鬆愉快。

 

開篇摘要

本文通過一個簡單的業務場景，來描述如何通過字串池化來減少記憶體中的重複字串例項，從而減少記憶體的佔用。

在業務中，我們假設如下：

  • 有一百萬個商品，每個商品都有一個 ProductId 和 Color 列儲存在資料庫中
  • 需要將所有的資料載入到記憶體中，作為快取使用
  • 每個產品都有 Color
  • Color 的範圍是一個有限的範圍，我們假設大約為八十個左右

學習 dotMemory 度量記憶體

既然需要度量記憶體優化的可靠性，那麼一個簡單有效的度量工具自然必不可少。

本篇，我們介紹 Rider + dotMemory 的組合，如何進行簡單的記憶體度量。讀者也可以根據自己的實際，選擇自己青睞的工具。

首先，我們建立一個單元測試專案，並且編寫一個簡單的記憶體字典構建過程:


public const int ProductCount = 1_000_000;

public static readonly List<string> Colors = new[]
    {
        "amber", // 此處實際上有80個左右的字串，省略篇幅
    }.OrderBy(x => x).ToList();

public static Dictionary<int, ProductInfo> CreateDict()
{
    var random = new Random(36524);
    var dict = new Dictionary<int, ProductInfo>(ProductCount);
    for (int i = 0; i < ProductCount; i++)
    {
        dict.Add(i, new ProductInfo
        {
            ProductId = i,
            Color = Colors[random.Next(0, Colors.Count)]
        });
    }

    return dict;
}

從以上程式碼可以看出：

  • 建立了一百萬個商品物件，其中的 Color 通過隨機數進行隨機選取。

提前指定字典的大小的預期值，實際上也是一種優化。請參閱 https://docs.microsoft.com/dotnet/api/system.collections.generic.dictionary-2.-ctor?view=net-5.0&WT.mc_id=DX-MVP-5003606#System_Collections_Generic_Dictionary_2__ctor_System_Int32_

然後，我們引入 dotMemory 單元測試度量必要的 nuget 包，和其他一些無關緊要的包:

<ItemGroup>
    <PackageReference Include="JetBrains.DotMemoryUnit" Version="3.1.20200127.214830" />

    <PackageReference Include="Humanizer" Version="2.11.10" />
</ItemGroup>

接著，我們建立一個簡單的測試來度量以上字典的建立前後，記憶體的變化：

public class NormalDictTest
{
    [Test]
    [DotMemoryUnit(FailIfRunWithoutSupport = false)]
    public void CreateDictTest()
    {
        var beforeStart = dotMemory.Check();
        var dict = HelperTest.CreateDict();
        GC.Collect();
        dotMemory.Check(memory =>
        {
            var snapshotDifference = memory.GetDifference(beforeStart);
            Console.WriteLine(snapshotDifference.GetNewObjects().SizeInBytes.Bytes());
        });
    }
}

從以上程式碼可以看出：

  • 在字典建立之前，我們通過dotMemory.Check()來捕捉當前記憶體的快照，以便後續進行對比
  • 字典建立完畢後，我們比對前後兩次檢查點中新增的物件的大小。

最後，點選如下圖所示的按鈕，執行這個測試：

run dotMemoryrun dotMemory

那麼，就會到的如下這樣的結果：

resultresult

故而，我們可以得出這樣一個簡單的結論。這樣一個字典，大約需要 61MB 的記憶體。

而這是理論上，這個字典佔用了記憶體最小情況。因為，其中每個 Color 使用的都是上面的八十個範圍之一。因此，他們達到了沒有任何重複例項的目的。

這個資料將會作為後續程式碼的一個基準。

嘗試從資料庫載入到記憶體

實際業務肯定是從資料庫之類的持久化儲存載入到記憶體中的。因此，我們度量一下，沒有經過優化情況下，這種載入方式大概需要多大的記憶體開銷。

這裡，我們使用 SQLite 作為演示的儲存資料庫，實際上用什麼都可以，因為我們關心的是最終快取的大小。

我們，引入一些無關緊要的包：

<ItemGroup>
    <PackageReference Include="Dapper" Version="2.0.90" />
    <PackageReference Include="System.Data.SQLite.Core" Version="1.0.115" />
</ItemGroup>

我們編寫一個測試程式碼，將一百萬測試資料寫入到測試庫中：

[Test]
public async Task CreateDb()
{
    var fileName = "data.db";
    if (File.Exists(fileName))
    {
        return;
    }

    var connectionString = GetConnectionString(fileName);
    await using var sqlConnection = new SQLiteConnection(connectionString);
    await sqlConnection.OpenAsync();
    await using var transaction = await sqlConnection.BeginTransactionAsync();
    await sqlConnection.ExecuteAsync(@"
CREATE TABLE Product(
    ProductId int PRIMARY KEY,
    Color TEXT
)", transaction);

    var dict = CreateDict();
    foreach (var (_, p) in dict)
    {
        await sqlConnection.ExecuteAsync(@"
INSERT INTO Product(ProductId,Color)
VALUES(@ProductId,@Color)", p, transaction);
    }

    await transaction.CommitAsync();
}

public static string GetConnectionString(string filename)
{
    var re =
        $"Data Source={filename};Cache Size=5000;Journal Mode=WAL;Pooling=True;Default IsolationLevel=ReadCommitted";
    return re;
}

以上程式碼：

  • 建立一個名為 data.db 的資料
  • 在資料庫中建立一個 Product 表，包含 ProductId 和 Color 兩列
  • 將字典中的所有資料插入到這兩個表中，其實就是前文建立的那個字典

執行這個測試，大概十秒左右，測試資料也就準備好了。後續，我們將重複從這個資料庫讀取資料，作為我們的測試用例。

現在，我們編寫一個從資料庫讀取資料，然後載入到字典的程式碼，並且度量一下記憶體的變化：

[Test]
[DotMemoryUnit(FailIfRunWithoutSupport = false)]
public async Task LoadFromDbAsync()
{
    var beforeStart = dotMemory.Check();
    var dict = new Dictionary<int, ProductInfo>(HelperTest.ProductCount);
    await LoadCoreAsync(dict);
    GC.Collect();
    dotMemory.Check(memory =>
    {
        var snapshotDifference = memory.GetDifference(beforeStart);
        Console.WriteLine(snapshotDifference.GetNewObjects().SizeInBytes.Bytes());
    });
}

public static async Task LoadCoreAsync(Dictionary<int, ProductInfo> dict)
{
    var connectionString = HelperTest.GetConnectionString();
    await using var sqlConnection = new SQLiteConnection(connectionString);
    await sqlConnection.OpenAsync();
    await using var reader = await sqlConnection.ExecuteReaderAsync(
        "SELECT ProductId, Color FROM Product");
    var rowParser = reader.GetRowParser<ProductInfo>();
    while (await reader.ReadAsync())
    {
        var productInfo = rowParser.Invoke(reader);
        dict[productInfo.ProductId] = productInfo;
    }
}

以上程式碼：

  • 我們改變了字典的建立方式，將其中的資料從資料庫中讀取並載入
  • 使用 Dapper 讀取 DataReader 並且全部載入字典

同樣，我們執行 dotMemory 度量變化，可以得到資料為：

95.1 MB

因此，我們得出，採用這種方式，多消耗了 30MB 左右的記憶體。看起來很少，但其實比前面多了 50%。（一千五工資加薪到三千，漲薪 100%的即時感）

當然，你可能會懷疑，多出來的這些開銷實際上是資料庫操作消耗的。但通過下文的優化，我們可以提前知道：

這些多出來的開銷，實際上是因為存在重複的字串消耗。

剔除重複的字串例項

既然我們懷疑多出來的開銷是重複的字串，那麼我們就可以考慮通過將它們轉為同一個物件的方式，減少字典中重複的字串。

所以，我們就有了下面這個版本的測試程式碼：

[Test]
[DotMemoryUnit(FailIfRunWithoutSupport = false)]
public async Task LoadFromDbAsync()
{
    var beforeStart = dotMemory.Check();
    var dict = new Dictionary<int, ProductInfo>(HelperTest.ProductCount);
    await DbReadingTest.LoadCoreAsync(dict);
    foreach (var (_, p) in dict)
    {
        var colorIndex = HelperTest.Colors.BinarySearch(p.Color);
        var color = HelperTest.Colors[colorIndex];
        p.Color = color;
    }
    GC.Collect();
    dotMemory.Check(memory =>
    {
        var snapshotDifference = memory.GetDifference(beforeStart);
        Console.WriteLine(snapshotDifference.GetNewObjects().SizeInBytes.Bytes());
    });
}

以上程式碼：

  • 我們仍然從資料庫載入所有的資料到字典中，載入的程式碼和先前完全一樣，因此沒有展示
  • 載入之後，我們再次遍歷字典。並且從早在第一個版本就存在的 Color List 搜尋到對應的字串例項，並且賦值給字典中的 Color
  • 通過這樣一搜，一讀，一換。我們使得字典中的 Color 全部來自 Color List

於是，我們再次執行 dotMemory 進行度量，結果非常的 Amazing：

61.69 MB

雖說，最終這個數字的開銷對比，第一個版本略有上升，但其實已經到了相差無幾的地步。

我們通過將相同字串轉為相同例項的方式，將字典中的相同 Color 轉為了相同例項。而 30MB 的臨時字串則會由於沒有物件引用它們，因此在最近的一次 GC 中會被立即回收，一切都是這樣的輕鬆愉快。

直接引入 StringPool

前文我們已經找到了開銷的原因，並且通過辦法進行了優化。不過還存在一些問題實際上要考慮：

  • 很多時候 Color List 並不是靜態的列表，她可能早上還很開心，下午就生氣了
  • Color List 不可能無限大，我們需要一個淘汰演算法，淘汰末尾的 10%，把他們輸送給社會

因此，我們可以考慮直接使用 StringPool，別人寫的程式碼很棒，現在是我們的了。

讓我們再引入一些無關緊要的包：

<ItemGroup>
    <PackageReference Include="Microsoft.Toolkit.HighPerformance" Version="7.0.2" />
</ItemGroup>

稍微改了一下，就有了新的版本：

[Test]
[DotMemoryUnit(FailIfRunWithoutSupport = false)]
public async Task LoadFromDbAsync()
{
    var beforeStart = dotMemory.Check();
    var dict = new Dictionary<int, ProductInfo>(HelperTest.ProductCount);
    await DbReadingTest.LoadCoreAsync(dict);
    var stringPool = StringPool.Shared;
    foreach (var (_, p) in dict)
    {
        p.Color = stringPool.GetOrAdd(p.Color);
    }
    GC.Collect();
    dotMemory.Check(memory =>
    {
        var snapshotDifference = memory.GetDifference(beforeStart);
        Console.WriteLine(snapshotDifference.GetNewObjects().SizeInBytes.Bytes());
    });
}

以上程式碼：

  • 使用了 StringPool.Shared 例項儲存字串例項
  • GetOrAdd 實際上就是實現了我們先前的一搜，一讀，一換三步走戰略

當然，結果也是毫無驚喜可言的驚喜：

61.81 MB

一切就是這樣的輕鬆愉快。

diffdiff

延伸閱讀

StringPool 和 string.Intern() 有什麼異同？

它們都是為了解決重複字串例項過多，導致浪費記憶體的情況。

效果上的區別，主要是生存期的區別。 string.Intern 是終生制的，一旦加入只要程式不重啟，就會一直存在。這和 StringPool 很不一樣。

因此，如果你有生存期上的考慮，請斟酌選擇。

string.Intern 可以參閱 https://docs.microsoft.com/dotnet/api/system.string.intern?view=net-5.0&WT.mc_id=DX-MVP-5003606

StringPool 是怎麼實現的？

我們也不懂，我們也不敢亂說。總的來說是一個帶有使用計數標記的優先佇列。原始碼我們也讀不懂。

前面的區域，就交給你探索吧：

https://github.com/CommunityToolkit/WindowsCommunityToolkit/blob/main/Microsoft.Toolkit.HighPerformance/Buffers/StringPool.cs

我該在什麼情況下考慮使用 StringPool？

筆者建議，考慮這些字串入池：

  1. 這個字串可能被很多例項引用
  2. 這個字串需要長期駐留，或者持有它的物件，是長期物件
  3. 記憶體優化確實已經成為你要考慮的事情了

當然，其實存在一個最容易判斷的依據。你可以直接把產線上的記憶體 dump 下來，檢視裡面是否存在很多重複的字串，然後優化他們。 現在已經是 2021 年了，不會還有人不會 dump 記憶體吧，不會吧，不會吧？（手動狗頭 如果你還不會 dump 記憶體，那麼可以參閱黃老師在微軟 Reactor 上分享的視訊進行學習： https://www.bilibili.com/video/BV1jZ4y1P7EY

好耶！我可以用 StringPool 來儲存列舉的 DisplayName

確實，也沒有什麼錯。不過，其實還有更好的一些方案:

https://github.com/Spinnernicholas/EnumFastToStringDotNet

本篇小結

dotMemory 度量還有更多姿勢，你可以多多嘗試。

重複，池化。這是一種非常常見的優化方案。掌握它們，在你需要的時候，這或許就幫到了你。

本篇文章中程式碼例項，可以在以下地址找到，不要忘記為專案 star 喲：

https://github.com/newbe36524/Newbe.Demo/tree/main/src/BlogDemos/Newbe.StringPools

字串池化，減少重複例項，記憶體降低，一切就是這樣的輕鬆愉快。



 

相關文章