Skip to content

Commit 7893bf1

Browse files
peffgitster
authored andcommitted
p5551: add a script to test fetch pack-dir rescans
Since fetch often deals with object-ids we don't have (yet), it's an easy mistake for it to use a function like parse_object() that gives the correct result (e.g., NULL) but does so very slowly (because after failing to find the object, we re-scan the pack directory looking for new packs). The regular test suite won't catch this because the end result is correct, but we would want to know about performance regressions, too. Let's add a test to the regression suite. Note that this uses a synthetic repository that has a large number of packs. That's not ideal, as it means we're not testing what "normal" users see (in fact, some of these problems have existed for ages without anybody noticing simply because a rescan on a normal repository just isn't that expensive). So what we're really looking for here is the spike you'd notice in a pathological case (a lot of unknown objects coming into a repo with a lot of packs). If that's fast, then the normal cases should be, too. Note that the test also makes liberal use of $MODERN_GIT for setup; some of these regressions go back a ways, and we should be able to use it to find the problems there. Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent 0a11e40 commit 7893bf1

File tree

1 file changed

+55
-0
lines changed

1 file changed

+55
-0
lines changed

t/perf/p5551-fetch-rescan.sh

Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
#!/bin/sh
2+
3+
test_description='fetch performance with many packs
4+
5+
It is common for fetch to consider objects that we might not have, and it is an
6+
easy mistake for the code to use a function like `parse_object` that might
7+
give the correct _answer_ on such an object, but do so slowly (due to
8+
re-scanning the pack directory for lookup failures).
9+
10+
The resulting performance drop can be hard to notice in a real repository, but
11+
becomes quite large in a repository with a large number of packs. So this
12+
test creates a more pathological case, since any mistakes would produce a more
13+
noticeable slowdown.
14+
'
15+
. ./perf-lib.sh
16+
. "$TEST_DIRECTORY"/perf/lib-pack.sh
17+
18+
test_expect_success 'create parent and child' '
19+
git init parent &&
20+
git clone parent child
21+
'
22+
23+
24+
test_expect_success 'create refs in the parent' '
25+
(
26+
cd parent &&
27+
git commit --allow-empty -m foo &&
28+
head=$(git rev-parse HEAD) &&
29+
test_seq 1000 |
30+
sed "s,.*,update refs/heads/& $head," |
31+
$MODERN_GIT update-ref --stdin
32+
)
33+
'
34+
35+
test_expect_success 'create many packs in the child' '
36+
(
37+
cd child &&
38+
setup_many_packs
39+
)
40+
'
41+
42+
test_perf 'fetch' '
43+
# start at the same state for each iteration
44+
obj=$($MODERN_GIT -C parent rev-parse HEAD) &&
45+
(
46+
cd child &&
47+
$MODERN_GIT for-each-ref --format="delete %(refname)" refs/remotes |
48+
$MODERN_GIT update-ref --stdin &&
49+
rm -vf .git/objects/$(echo $obj | sed "s|^..|&/|") &&
50+
51+
git fetch
52+
)
53+
'
54+
55+
test_done

0 commit comments

Comments
 (0)