summaryrefslogtreecommitdiff
path: root/prune-packed.h
diff options
context:
space:
mode:
authorLibravatar Patrick Steinhardt <ps@pks.im>2021-08-04 15:56:11 +0200
committerLibravatar Junio C Hamano <gitster@pobox.com>2021-08-04 10:45:32 -0700
commit3e5e6c6e94f09973d3a72049aad09fd2131a3648 (patch)
tree135ae9f357510ec4fadc056509b42629664d3ce3 /prune-packed.h
parentGit 2.32 (diff)
downloadtgif-3e5e6c6e94f09973d3a72049aad09fd2131a3648.tar.xz
fetch-pack: speed up loading of refs via commit graph
When doing reference negotiation, git-fetch-pack(1) is loading all refs from disk in order to determine which commits it has in common with the remote repository. This can be quite expensive in repositories with many references though: in a real-world repository with around 2.2 million refs, fetching a single commit by its ID takes around 44 seconds. Dominating the loading time is decompression and parsing of the objects which are referenced by commits. Given the fact that we only care about commits (or tags which can be peeled to one) in this context, there is thus an easy performance win by switching the parsing logic to make use of the commit graph in case we have one available. Like this, we avoid hitting the object database to parse these commits but instead only load them from the commit-graph. This results in a significant performance boost when executing git-fetch in said repository with 2.2 million refs: Benchmark #1: HEAD~: git fetch $remote $commit Time (mean ± σ): 44.168 s ± 0.341 s [User: 42.985 s, System: 1.106 s] Range (min … max): 43.565 s … 44.577 s 10 runs Benchmark #2: HEAD: git fetch $remote $commit Time (mean ± σ): 19.498 s ± 0.724 s [User: 18.751 s, System: 0.690 s] Range (min … max): 18.629 s … 20.454 s 10 runs Summary 'HEAD: git fetch $remote $commit' ran 2.27 ± 0.09 times faster than 'HEAD~: git fetch $remote $commit' Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'prune-packed.h')
0 files changed, 0 insertions, 0 deletions