merge-base performance #4765
Merged
merge-base performance #4765
Conversation
This file contains hidden or 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
That way, it can leverage already held commit-objects, and be faster in the absence of a commitgraph.
|
@Byron is attempting to deploy a commit to the GitButler Team on Vercel. A member of the Team first needs to authorize it. |
This time, it contains whole commits and only flags are reset between runs. With this amount of re-use, it will manage to rival `git2`.
12 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Follow-up to #4757.
Get
merge-basecomputation performance to be en-par with the cache-less variant ingit2.Prevously when there is no commit-graph cache, it was 7% slower than
git2(which is just as fast as Git itself),which is likely due to Git2 leveraging already parsed objects between multiple merge-base queries.
gixhas to learn that to be en-par or faster, and I think it's not going to take long.Tasks
git2for merge-bases. (from 6% slower to 8% faster)gix(that can re-use the existing commit-graph cache (with parsed objects)Performance
This was a win, as
gixis now about 4% faster than Git (in one particular workload without commit-graph), and 8% faster thangit2thanks to greatly improved caching.Memory consumption is still lower at 575MB compared to 617MB.
When a commit-graph is present (via
git commit-graph write --reachable), thengixis 26% faster. Now it probably hits the boundary where diffing trees is the slowest operation, whereas merge-base computation is very quickly done (it's at least 10x faster then). Those who have repos big enough to use commit-graphs will certainly appreciate it.