summaryrefslogtreecommitdiff
path: root/t/perf/p5304-prune.sh
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2019-02-14 04:35:22 (GMT)
committerJunio C Hamano <gitster@pobox.com>2019-02-14 23:25:32 (GMT)
commitd55a30bb1db565751f5bba5c5f9c344b08771ab2 (patch)
treef949dd6d09be3e59b1a3aded4c0c2ef4f7fd9d7c /t/perf/p5304-prune.sh
parent2d08f3deb9feb73dc8d21d75bfd367839fc1322c (diff)
downloadgit-d55a30bb1db565751f5bba5c5f9c344b08771ab2.zip
git-d55a30bb1db565751f5bba5c5f9c344b08771ab2.tar.gz
git-d55a30bb1db565751f5bba5c5f9c344b08771ab2.tar.bz2
prune: lazily perform reachability traversal
The general strategy of "git prune" is to do a full reachability walk, then for each loose object see if we found it in our walk. But if we don't have any loose objects, we don't need to do the expensive walk in the first place. This patch postpones that walk until the first time we need to see its results. Note that this is really a specific case of a more general optimization, which is that we could traverse only far enough to find the object under consideration (i.e., stop the traversal when we find it, then pick up again when asked about the next object, etc). That could save us in some instances from having to do a full walk. But it's actually a bit tricky to do with our traversal code, and you'd need to do a full walk anyway if you have even a single unreachable object (which you generally do, if any objects are actually left after running git-repack). So in practice this lazy-load of the full walk catches one easy but common case (i.e., you've just repacked via git-gc, and there's nothing unreachable). The perf script is fairly contrived, but it does show off the improvement: Test HEAD^ HEAD ------------------------------------------------------------------------- 5304.4: prune with no objects 3.66(3.60+0.05) 0.00(0.00+0.00) -100.0% and would let us know if we accidentally regress this optimization. Note also that we need to take special care with prune_shallow(), which relies on us having performed the traversal. So this optimization can only kick in for a non-shallow repository. Since this is easy to get wrong and is not covered by existing tests, let's add an extra test to t5304 that covers this case explicitly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/perf/p5304-prune.sh')
-rwxr-xr-xt/perf/p5304-prune.sh24
1 files changed, 24 insertions, 0 deletions
diff --git a/t/perf/p5304-prune.sh b/t/perf/p5304-prune.sh
new file mode 100755
index 0000000..3c85208
--- /dev/null
+++ b/t/perf/p5304-prune.sh
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+test_description='performance tests of prune'
+. ./perf-lib.sh
+
+test_perf_default_repo
+
+test_expect_success 'remove reachable loose objects' '
+ git repack -ad
+'
+
+test_expect_success 'remove unreachable loose objects' '
+ git prune
+'
+
+test_expect_success 'confirm there are no loose objects' '
+ git count-objects | grep ^0
+'
+
+test_perf 'prune with no objects' '
+ git prune
+'
+
+test_done