On 04/06, [email protected] wrote: > From: Jeff Hostetler <[email protected]> > > Signed-off-by: Jeff Hostetler <[email protected]> > --- > t/perf/p0005-status.sh | 61 > ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 61 insertions(+) > create mode 100755 t/perf/p0005-status.sh > > diff --git a/t/perf/p0005-status.sh b/t/perf/p0005-status.sh > new file mode 100755 > index 0000000..704cebc > --- /dev/null > +++ b/t/perf/p0005-status.sh > @@ -0,0 +1,61 @@ > +#!/bin/sh > + > +test_description="Tests performance of read-tree" > + > +. ./perf-lib.sh > + > +test_perf_default_repo > +test_checkout_worktree > + > +## usage: dir depth width files > +make_paths () { > + for f in $(seq $4) > + do > + echo $1/file$f > + done; > + if test $2 -gt 0; > + then > + for w in $(seq $3) > + do > + make_paths $1/dir$w $(($2 - 1)) $3 $4 > + done > + fi > + return 0 > +} > + > +fill_index () { > + make_paths $1 $2 $3 $4 | > + sed "s/^/100644 $EMPTY_BLOB /" | > + git update-index --index-info > + return 0 > +} > + > +br_work1=xxx_work1_xxx > +dir_new=xxx_dir_xxx > + > +## (5, 10, 9) will create 999,999 files. > +## (4, 10, 9) will create 99,999 files. > +depth=5 > +width=10 > +files=9 > + > +## Inflate the index with thousands of empty files and commit it. > +## Use reset to actually populate the worktree. > +test_expect_success 'inflate the index' ' > + git reset --hard && > + git branch $br_work1 && > + git checkout $br_work1 && > + fill_index $dir_new $depth $width $files && > + git commit -m $br_work1 && > + git reset --hard > +' > + > +## The number of files in the branch. > +nr_work1=$(git ls-files | wc -l)
The above seems to be repeated (or at least very similar to what you have in your other series [1]. Especially in this perf test wouldn't it be better just use test_perf_large_repo, and let whoever runs the test decide what constitutes a large repository for them? The other advantage of that would be that it is more of a real-world scenario, instead of a synthetic distribution of the files, which would give us some better results I think. Is there anything I'm missing that would make using test_perf_large_repo not a good option here? [1]: http://public-inbox.org/git/[email protected]/ > +test_perf "read-tree status work1 ($nr_work1)" ' > + git read-tree HEAD && > + git status > +' > + > +test_done > -- > 2.9.3 >
