git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: Jeff Hostetler via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Jeff Hostetler <jeffhost@microsoft.com>
Subject: Re: [PATCH] t/perf/perf-lib.sh: remove test_times.* at the end test_perf_()
Date: Sun, 10 Oct 2021 23:26:26 +0200	[thread overview]
Message-ID: <20211010212626.GB571180@szeder.dev> (raw)
In-Reply-To: <YVyPH59LpxFLHep0@nand.local>

On Tue, Oct 05, 2021 at 01:45:03PM -0400, Taylor Blau wrote:
> 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'.


  parent reply	other threads:[~2021-10-10 21:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-04 22:29 [PATCH] t/perf/perf-lib.sh: remove test_times.* at the end test_perf_() Jeff Hostetler via GitGitGadget
2021-10-05 17:45 ` Taylor Blau
2021-10-06 19:24   ` Jeff King
2021-10-06 19:26     ` Taylor Blau
2021-10-07 17:49     ` Jeff Hostetler
2021-10-08  2:55       ` Jeff King
2021-10-08  7:47         ` A hard dependency on "hyperfine" for t/perf Ævar Arnfjörð Bjarmason
2021-10-08 17:30         ` [PATCH] t/perf/perf-lib.sh: remove test_times.* at the end test_perf_() Junio C Hamano
2021-10-08 19:57           ` Jeff King
2021-10-10 21:26   ` SZEDER Gábor [this message]
2021-10-13 21:09     ` Jeff Hostetler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211010212626.GB571180@szeder.dev \
    --to=szeder.dev@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jeffhost@microsoft.com \
    --cc=me@ttaylorr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).