[Bug]Regression perfomance since 5.2.4

[Rafikys12]

Describe the bug
the code in TaggedCommitVersionStrategy has been change in 5.2.0 with this code

        var tagsOnBranch = currentBranch
            .Commits
            .SelectMany(commit => { return allTags.Where(t => IsValidTag(t.Item1, commit)); })
            .Select(t =>
            {
                if (t.Item1.PeeledTarget() is Commit)
                    return new VersionTaggedCommit(t.Item1.PeeledTarget() as Commit, t.Item2, t.Item1.FriendlyName);

                return null;
            })
            .Where(a => a != null)
            .Take(5)
            .ToList();

in Mainline mode, it avoid to list all tags

In 5.10.0, the code change and it list all tag, it cause gitversion is very slow in our buildchain (almost 40 minutes)

Expected Behavior

gitversion eecute quickly

Actual Behavior

gitversion very slow

Possible Fix

same as 5.2.4

Steps to Reproduce

Context

In our buildchain, we use repo with many version in githubflow each build is tagged so we have more than 3000 tags.
Gitversion start to be very slow since 5.0.0, so we try to upgrade to 5.10.0. after many research, we found something similar here
#2149
it appear that it fixes our problem

Your Environment

• Version Used:
  windows 10 64 bit

[asbjornu]

If you have ideas on how to improve the performance, pull requests are welcome! 🙏🏼

[kkolman]

Seeing similar performance regression (5.12.0, 6.0.0-beta2).

Here's a test setup, straight out-of-the-box, no GitVersion.yml config:

mkdir /tmp/gitversion-test
cd /tmp/gitversion-test/
git init

Generate 2000 commits, every other commit is tagged 0.50.1, 0.50.2, ..., 0.50.1000

 for i in {1..1000}; do touch $i && git add * && git commit -m "commit $i"  && git tag 0.50.$i && touch a$i && git add . && git commit -m "non-tagged-commit $i"; done

Run time gitversion /nocache /showvariable FullSemVer:

• 5.9.0

real	0m0,727s
user	0m0,583s
sys	0m0,125s

• 5.12.0

real	0m16,845s
user	0m9,121s
sys	0m7,762s

• 6.0.0-beta2

real	0m15,856s
user	0m8,049s
sys	0m7,951s

When tripling the commit count to 6000 the numbers grow:

• 5.9.0 => 0m1,712
• 5.12.0 => 2m15,149s
• 6.0.0-beta2 => 2m4,320s

[asbjornu]

This seems like something we should be able to reproduce in a test. If anyone wants to tackle that, we would of course welcome pull requests. Perhaps we could even introduce BenchmarkDotNet with such a test, to ensure the performance doesn't regress once we've fixed it.

[arturcic]

🎉 This issue has been resolved in version 6.0.0-beta.3 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀