Fix TaggedCommitVersionStrategy performance problems #2800
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The problem was a branch commits x version tags nested loop that quickly grew into the millions of iterations as the number of commits and/or tags in a repo increased, even modestly. Each iteration performed Git tag-to-commit resolution and GitVersion commit object-to-object comparison, both of which take a little bit of time and aren't particularly slow in isolation but which add up fast when performed millions of times. This is solved by doing a single pass over the tags, resolving each to a commit only once; then using that to build a commit-to-tag lookup (hashtable) keyed by commit SHA, eliminating the object comparisons; and finally doing a single pass over the branch commits, looking up associated tags from the hashtable by SHA, eliminating the nested loop. Testing on a repo with ~20,000 commits and ~5,000 tags showed an overall GitVersion run time reduction from over 2 minutes down to around 5 seconds.
asbjornu
requested changes
Aug 9, 2021
src/GitVersion.Core/VersionCalculation/BaseVersionCalculators/TaggedCommitVersionStrategy.cs
Outdated
Show resolved
Hide resolved
…TaggedCommitVersionStrategy.cs Co-authored-by: Asbjørn Ulsberg <[email protected]>
|
Can you please run |
|
Sorry, my mistake: I hadn't pulled the PR feedback change. |
auto-merge was automatically disabled
August 10, 2021 03:21
Head branch was pushed to by a user without write access
asbjornu
approved these changes
Aug 10, 2021
|
Thank you @ron-macneil-youi for your contribution! |
|
🎉 This issue has been resolved in version 5.7.0 🎉 Your GitReleaseManager bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The problem was a branch commits x version tags nested loop that quickly
grew into the millions of iterations as the number of commits and/or
tags in a repo increased, even modestly.
Each iteration performed Git tag-to-commit resolution and GitVersion
commit object-to-object comparison, both of which take a little bit of
time and aren't particularly slow in isolation but which add up fast
when performed millions of times.
This is solved by doing a single pass over the tags, resolving each to a
commit only once; then using that to build a commit-to-tag lookup
(hashtable) keyed by commit SHA, eliminating the object comparisons; and
finally doing a single pass over the branch commits, looking up
associated tags from the hashtable by SHA, eliminating the nested loop.
Testing on a repo with ~20,000 commits and ~5,000 tags showed an overall
GitVersion run time reduction from over 2 minutes down to around 5
seconds.
Description
Related Issue
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Checklist: