Performance regression when reading files from the tree in parallel

Reproduction steps

1. Add the following test cases in CommitFixture.cs:

[Fact]
public void CanReadCommit()
{
    var timer = new Stopwatch();
    var fileContents = new ConcurrentStack<string>();
    var path = SandboxStandardTestRepo();
    using (var repo = new Repository(path))
    {
        var latestCommit = repo.Head.Tip;
        var tree = latestCommit.Tree;
        timer.Start();
        for (var i = 0; i < 100000; i++)
        {
            fileContents.Push(ReadEntry("1.txt", tree));
            fileContents.Push(ReadEntry("README", tree));
            fileContents.Push(ReadEntry("new.txt", tree));
        }
        timer.Stop();
        testOutputHelper.WriteLine($"Took: {timer.ElapsedMilliseconds.ToString()}ms");
        Assert.Equal(300000, fileContents.Count);
    }
}

[Fact]
public void CanReadCommitParallel()
{
    var timer = new Stopwatch();
    var fileContents = new ConcurrentStack<string>();
    var path = SandboxStandardTestRepo();
    using (var repo = new Repository(path))
    {
        var latestCommit = repo.Head.Tip;
        var tree = latestCommit.Tree;
        timer.Start();
        var fileNames = new List<string>() {"1.txt", "README", "new.txt"}.AsEnumerable();
        Parallel.ForEach(fileNames, (fileName) =>
        {
            for (var i = 0; i < 100000; i++)
            {
                fileContents.Push(ReadEntry(fileName, tree));
            }
        });
        timer.Stop();
        testOutputHelper.WriteLine($"Took: {timer.ElapsedMilliseconds.ToString()}ms");
        Assert.Equal(300000, fileContents.Count);
    }
}

private static string ReadEntry(string name, Tree tree)
{
    var treeEntry = tree[name];
    if (treeEntry != null && treeEntry.Target is Blob blob)
    {
        return blob.GetContentText();
    }

    throw new InvalidOperationException($"{name} must be a Blob");
}

2. Run against version 0.27.0-preview-0119 (commit: 6329bea). On my machine, CanReadCommitParallel takes 1417ms and CanReadCommit takes 2971ms (which is fine)
3. Checkout the latest version or the latest release
4. Run the test again. On my machine, CanReadCommitParallel takes 3731ms and CanReadCommit takes 3250ms!

Expected behavior

Reading files in parallel should be faster than reading files sequentially from the git tree.

Actual behavior

It seems that reading files from the tree in parallel (multi-thread) is not faster. I did a git bisect and it seems that this regression was introduced in https://github.com/libgit2/libgit2sharp/commit/21d4f13ac7c739a5526cf088fbd8765d4ad12f57

Version of LibGit2Sharp (release number or SHA1)

Versions after https://github.com/libgit2/libgit2sharp/commit/21d4f13ac7c739a5526cf088fbd8765d4ad12f57

Operating system(s) tested; .NET runtime tested

.NET 6 and .NET 7.

Beginnen Sie in CommitFixture.cs, indem Sie die sequenziellen und Parallel.ForEach-Reproduktionen gegen die im Bericht genannten Versionen hinzufügen und ausführen. Vergleichen Sie das Verhalten beim Lesen von Trees und Blobs rund um Commit 21d4f13ac7c739a5526cf088fbd8765d4ad12f57 unter .NET 6 und .NET 7. Als erledigt gilt die Aufgabe, wenn parallele Lesevorgänge die korrekte Anzahl beibehalten und bei einem vergleichbaren Lauf schneller als sequenzielle Lesevorgänge sind.