Huge amount of memory used.

[ganju001]

Prerequisites

• I have written a descriptive issue title
• I have searched issues to ensure it has not already been reported

GitVersion package

GitVersion.Portable

GitVersion version

6.0.1

Operating system

Windows

What are you seeing?

Hello community,

We have mono-repo that is more that few gigabytes in size. We were using gitversion 5.x and it was calculating
the version in 15 minutes, after updating to gitversion 6.x, I got huge memory (RAM) usage: 40GB+ (yes 40, no mistake) and more than 2 hours...

Any suggestions?

What is expected?

I expect it will calculate version with reasonable RAM usage and time.

Steps to Reproduce

Internal repo..

RepositoryFixture Test

No response

Output log or link to your CI build (if appropriate).

[HHobeck]

I would suggest to wait until version v6.2 has been released. After that please analyze your execution and create a memory dump. You need to narrow down the locaction where the memory is allocated or the CPU time is used. I'm going to move this to the discussion forum.

Cheers

[ganju001]

@HHobeck I have a memory dump, I can try to give some insights, the problem is that LibGit2Sharp creates objects which takes gigabytes, gitversion wraps those objects (commits, collections) and those take gigabytes too, I Saw 400M+ of references and 300M+ of objects created.

Normal branches (non DevOps PR ones) takes ~1minute and 7GB RAM to calculate (that is kind of acceptable); but the PR ones are taking ages and more that expected RAM..

[HHobeck]

@HHobeck I have a memory dump, I can try to give some insights, the problem is that LibGit2Sharp creates objects which takes gigabytes, gitversion wraps those objects (commits, collections) and those take gigabytes too, I Saw 400M+ of references and 300M+ of objects created.

Normal branches (non DevOps PR ones) takes ~1minute and 7GB RAM to calculate (that is kind of acceptable); but the PR ones are taking ages and more that expected RAM..

We had some performance improvement in the upcoming version. Please wait with the analyzis. You say that LibGit2Sharp uses to much memory... Maybe we have a memory leak there. Normally the calls to LibGit2Sharp are wrapped and the results are cached. A code review might be an idea having this in mind.

[ganju001]

@HHobeck Few questions:

• Do we have some branch that I can try?
• I doubt it is memory leak, as the memory usage goes up and down many times. It seems like a caching. And having 300 000 000+ objects in memory for cache is an issue for sure. Too many strings are created too...

This is somewhere in the middle of calculation:

In example:
Commit person name/email strings takes 1.3GB. Some names are repeated 20k+ times - duplicates.

[HHobeck]

Do we have some branch that I can try?

The main branch includes the latest development version. If you want to do changes please fork the repository and create a feature branch. By creating a pull requst you can merge it back to the main branch of gitversion.

Commit person name/email strings takes 1.3GB. Some names are repeated 20k+ times - duplicates.

This properties are not really necessary for calculating the next version number. I'm not sure if we have it in control

[ganju001]

@HHobeck Any progress?

[HHobeck]

I cannot find the problem in LigGit2Sharp. I think I need more statistics:

internal sealed class AtomicInteger
{
    private int value;

    public int Value => value;

    public AtomicInteger()
    {
    }

    public AtomicInteger(int value) => this.value = value;

    public int Increment() => Interlocked.Increment(ref value);
}

internal static class CommitStatistics
{
    public static readonly AtomicInteger CommitInstanceCreateCount = new();
    public static readonly ConcurrentDictionary<string, AtomicInteger> CommitInstanceCreateCountBySha = new();
    public static readonly ConcurrentDictionary<int, AtomicInteger> CommitInstanceCreateCountByHasHCode = new();

    internal static void CountCommitInstanceCreated(LibGit2Sharp.Commit commit)
    {
        CommitInstanceCreateCount.Increment();
        CommitInstanceCreateCountBySha.GetOrAdd(commit.Sha, _ => new AtomicInteger()).Increment();
        CommitInstanceCreateCountByHasHCode.GetOrAdd(commit.GetHashCode(), _ => new AtomicInteger()).Increment();
    }
}

internal static class BranchStatistics
{
    public static readonly AtomicInteger BranchInstanceCreateCount = new();
    public static readonly ConcurrentDictionary<string, AtomicInteger> BranchInstanceCreateCountByCanonicalName = new();
    public static readonly ConcurrentDictionary<int, AtomicInteger> BranchInstanceCreateCountByHasHCode = new();

    internal static void CountBranchInstanceCreated(LibGit2Sharp.Branch branch)
    {
        BranchInstanceCreateCount.Increment();
        BranchInstanceCreateCountByCanonicalName.GetOrAdd(branch.CanonicalName, _ => new AtomicInteger()).Increment();
        BranchInstanceCreateCountByHasHCode.GetOrAdd(branch.GetHashCode(), _ => new AtomicInteger()).Increment();
    }
}

internal static class TagStatistics
{
    public static readonly AtomicInteger TagInstanceCreateCount = new();
    public static readonly ConcurrentDictionary<string, AtomicInteger> TagInstanceCreateCountByCanonicalName = new();
    public static readonly ConcurrentDictionary<int, AtomicInteger> TagInstanceCreateCountByHasHCode = new();

    internal static void CountTagInstanceCreated(LibGit2Sharp.Tag tag)
    {
        TagInstanceCreateCount.Increment();
        TagInstanceCreateCountByCanonicalName.GetOrAdd(tag.CanonicalName, _ => new AtomicInteger()).Increment();
        TagInstanceCreateCountByHasHCode.GetOrAdd(tag.GetHashCode(), _ => new AtomicInteger()).Increment();
    }
}

internal sealed class Commit : GitObject, ICommit
{
    ...
    private readonly LibGit2Sharp.Commit innerCommit;

    internal Commit(LibGit2Sharp.Commit innerCommit) : base(innerCommit)
    {
        CommitStatistics.CountCommitInstanceCreated(innerCommit);
        this.innerCommit = innerCommit.NotNull();
        ...
    }
...

[asbjornu]

Ideally we need to do the filtering ourselves in-memory on the already fetched commit collection.

I've thought about creating our own filtering abstraction before. I think this is our most complicated and "deep" integration with LibGit2Sharp making other implementations difficult or even impossible. Adding our own abstraction on top which only exposes exactly the functionality GitVersion needs as well as handling caching would also make testing and other implementations faster and easier. I'm afraid the functionality offered by CommitFilter is difficult to replicate and abstract, though.

[ganju001]

@HHobeck what kind of statistics you would need? Should I make some sort of mock repository?
I am not sure how to make it easy as I can not expose internal repo, maybe there is a tool that strips out all the content and commit messages and all other stuff?

[HHobeck]

@HHobeck what kind of statistics you would need? Should I make some sort of mock repository? I am not sure how to make it easy as I can not expose internal repo, maybe there is a tool that strips out all the content and commit messages and all other stuff?

If we could have a repository where we are able to connect to would be phantastic. It might be an idea to reply your repository and anonymize the commit and author information.