Re: [PATCH v3 24/34] t/perf/p7519: speed up test using "test-tool touch"
- From
- Jeff Hostetler <git@jeffhostetler.com>
- Date
- Jul 13, 2021, 18:04 UTC
- Message-ID
- <fae8cdcd-8222-b253-f656-d9f5b76de001@jeffhostetler.com>
- In-Reply-To
- <f1ef9656fc3adf079c8e40a74baeb5356bcf1586.1625150864.git.gitgitgadget@gmail.com>
On 7/1/21 10:47 AM, Jeff Hostetler via GitGitGadget wrote:
Show 30 quoted lines
> From: Jeff Hostetler <jeffhost@microsoft.com> > > Change p7519 to use a single "test-tool touch" command to update > the mtime on a series of (thousands) files instead of invoking > thousands of commands to update a single file. > > This is primarily for Windows where process creation is so > very slow and reduces the test run time by minutes. > > Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> > --- > t/perf/p7519-fsmonitor.sh | 14 ++++++-------- > 1 file changed, 6 insertions(+), 8 deletions(-) > > diff --git a/t/perf/p7519-fsmonitor.sh b/t/perf/p7519-fsmonitor.sh > index 5eb5044a103..f74e6014a0a 100755 > --- a/t/perf/p7519-fsmonitor.sh > +++ b/t/perf/p7519-fsmonitor.sh > @@ -119,10 +119,11 @@ test_expect_success "one time repo setup" ' > fi && > > mkdir 1_file 10_files 100_files 1000_files 10000_files && > - for i in $(test_seq 1 10); do touch 10_files/$i; done && > - for i in $(test_seq 1 100); do touch 100_files/$i; done && > - for i in $(test_seq 1 1000); do touch 1000_files/$i; done && > - for i in $(test_seq 1 10000); do touch 10000_files/$i; done && > + test-tool touch sequence --pattern="10_files/%d" --start=1 --count=10 && > + test-tool touch sequence --pattern="100_files/%d" --start=1 --count=100 && > + test-tool touch sequence --pattern="1000_files/%d" --start=1 --count=1000 && > + test-tool touch sequence --pattern="10000_files/%d" --start=1 --count=10000 &&
The big win in taking *minutes* off of the run time of this test was getting rid of the `for` loops and one `touch` invocation per file.
So whether we keep my `test-tool touch` command or switch to `test_seq` or `seq` is open for debate. Mine seems quicker, but it is more or less round off error in the larger picture considering what we started with.
I'll play with this a bit. Jeff