git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] t/perf/perf-lib.sh: remove test_times.* at the end test_perf_()

From
SZEDER Gábor <szeder.dev@gmail.com>
Date
Oct 10, 2021, 21:26 UTC
Message-ID
<20211010212626.GB571180@szeder.dev>
In-Reply-To
<YVyPH59LpxFLHep0@nand.local>
On Tue, Oct 05, 2021 at 01:45:03PM -0400, Taylor Blau wrote:
Show 43 quoted lines
> On Mon, Oct 04, 2021 at 10:29:03PM +0000, Jeff Hostetler via GitGitGadget wrote:
> > From: Jeff Hostetler <jeffhost@microsoft.com>
> >
> > Teach test_perf_() to remove the temporary test_times.* files
> 
> Small nit: s/test_times/test_time here and throughout.
> 
> > at the end of each test.
> >
> > test_perf_() runs a particular GIT_PERF_REPEAT_COUNT times and creates
> > ./test_times.[123...].  It then uses a perl script to find the minimum
> > over "./test_times.*" (note the wildcard) and writes that time to
> > "test-results/<testname>.<testnumber>.result".
> >
> > If the repeat count is changed during the pXXXX test script, stale
> > test_times.* files (from previous steps) may be included in the min()
> > computation.  For example:
> >
> > ...
> > GIT_PERF_REPEAT_COUNT=3 \
> > test_perf "status" "
> > 	git status
> > "
> >
> > GIT_PERF_REPEAT_COUNT=1 \
> > test_perf "checkout other" "
> > 	git checkout other
> > "
> > ...
> >
> > The time reported in the summary for "XXXX.2 checkout other" would
> > be "min( checkout[1], status[2], status[3] )".
> >
> > We prevent that error by removing the test_times.* files at the end of
> > each test.
> 
> Well explained, and makes sense to me. I didn't know we set
> GIT_PERF_REPEAT_COUNT inline with the performance tests themselves, but
> grepping shows that we do it in the fsmonitor tests.
> 
> Dropping any test_times files makes sense as the right thing to do. I
> have no opinion on whether it should happen before running a perf test,
> or after generating the results. So what you did here looks good to me.

I think it's better to remove those files before running the perf test, and leave them behind after the test finished. This would give developers an opportunity to use the timing results for whatever other statistics they might be interested in.

And yes, I think it would be better if 'make test' left behind 't/test-results' with all the test trace output for later analysis as well. E.g. grepping through the test logs can uncover bugs like this:

  https://public-inbox.org/git/20211010172809.1472914-1-szeder.dev@gmail.com/

and I've fixed several similar test bugs that I've found when looking through 'test-results/*.out'. Alas, it's always a bit of a hassle to comment out 'make clean-except-prove-cache' in 't/Makefile'.

Previous: Jeff KingNext: Jeff Hostetler
Message 10 of 11 in “t/perf/perf-lib.sh: remove test_times.* at the end test_perf_()”
  1. t/perf/perf-lib.sh: remove test_times.* at the end test_perf_()Jeff Hostetler via GitGitGadget, Oct 4, 2021
  2. Taylor BlauOct 5, 2021
  3. Jeff KingOct 6, 2021
  4. Taylor BlauOct 6, 2021
  5. Jeff HostetlerOct 7, 2021
  6. Jeff KingOct 8, 2021
  7. A hard dependency on "hyperfine" for t/perfÆvar Arnfjörð Bjarmason, Oct 8, 2021
  8. Junio C HamanoOct 8, 2021
  9. Jeff KingOct 8, 2021
  10. SZEDER GáborOct 10, 2021
  11. Jeff HostetlerOct 13, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.