summaryrefslogtreecommitdiff
path: root/t/t4013
diff options
context:
space:
mode:
authorLibravatar Patrick Steinhardt <ps@pks.im>2022-02-10 13:28:09 +0100
committerLibravatar Junio C Hamano <gitster@pobox.com>2022-02-10 09:59:38 -0800
commit6fd1cc8f985ccd8b014e945a819482b267dae21f (patch)
tree4308a59316dbc99a36980548b1cc97f50d90a54b /t/t4013
parentThe second batch for 2.36 (diff)
downloadtgif-6fd1cc8f985ccd8b014e945a819482b267dae21f.tar.xz
fetch-pack: use commit-graph when computing cutoff
During packfile negotiation we iterate over all refs announced by the remote side to check whether their IDs refer to commits already known to us. If a commit is known to us already, then its date is a potential cutoff point for commits we have in common with the remote side. There is potentially a lot of commits announced by the remote depending on how many refs there are in the remote repository, and for every one of them we need to search for it in our object database and, if found, parse the corresponding object to find out whether it is a candidate for the cutoff date. This can be sped up by trying to look up commits via the commit-graph first, which is a lot more efficient. Benchmarks in a repository with about 2,1 million refs and an up-to-date commit-graph show an almost 20% speedup when mirror-fetching: Benchmark 1: git fetch +refs/*:refs/* (v2.35.0) Time (mean ± σ): 115.587 s ± 2.009 s [User: 109.874 s, System: 11.305 s] Range (min … max): 113.584 s … 118.820 s 5 runs Benchmark 2: git fetch +refs/*:refs/* (HEAD) Time (mean ± σ): 96.859 s ± 0.624 s [User: 91.948 s, System: 10.980 s] Range (min … max): 96.180 s … 97.875 s 5 runs Summary 'git fetch +refs/*:refs/* (HEAD)' ran 1.19 ± 0.02 times faster than 'git fetch +refs/*:refs/* (v2.35.0)' Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t4013')
0 files changed, 0 insertions, 0 deletions