From: Jeff King <peff@peff.net>
To: Derrick Stolee <stolee@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] p5310: stop timing non-bitmap pack-to-disk
Date: Thu, 26 Mar 2020 07:12:01 -0400 [thread overview]
Message-ID: <20200326111201.GA4193632@coredump.intra.peff.net> (raw)
In-Reply-To: <cf64c47a-481e-3802-3ce6-a2a583cd7c75@gmail.com>
On Thu, Mar 26, 2020 at 06:48:37AM -0400, Derrick Stolee wrote:
> > - the point of the t/perf suite is to find performance regressions,
> > and it won't help with that. We don't compare the numbers between
> > two tests (which the perf suite has no idea are even related), and
> > any change in its numbers would have nothing to do with bitmaps.
>
> This does make me think if there is a way to adjust "./run" to test two
> different config settings or command-line options instead of just two
> different build versions. Perhaps something like
>
> ./run "HEAD -c core.commitGraph=true" "HEAD -c core.commitGraph=false" -- p4200-line-log.sh
>
> But that's just musing on my part.
I think that's the right direction, but it would require tests knowing
how to make use of those extra parameters. What I'd _really_ like is a
way to parameterize a whole bunch of things:
- test repo
- git version
- particular config settings
do runs with whatever combinations of parameters you choose, and then
create tables showing differences across various settings of a
parameter. Some parameters would be automatically set up, but test
scripts would have to advertise other parameters they know about.
I don't think it's conceptually hard, but the existing perf code is
pretty hacked-together and relies on the filesystem for storage. So the
notion that we'd only ever compare different versions runs deep; that's
how the on-disk storage is organized.
> > So let's just drop it. It's not useful and is adding minutes to perf
> > runs.
>
> I agree with your reasoning. This is not a critical path for clients,
> and all servers should be using bitmaps.
Yeah, I should have noted that we're not actually testing the
performance of a stock repack anywhere else. It wouldn't belong in
p5310, but in theory it might be of interest in another script. But I
agree for the reasons you gave that it's not all that interesting a
timing.
-Peff
prev parent reply other threads:[~2020-03-26 11:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-26 7:54 [PATCH] p5310: stop timing non-bitmap pack-to-disk Jeff King
2020-03-26 10:48 ` Derrick Stolee
2020-03-26 11:12 ` Jeff King [this message]
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=20200326111201.GA4193632@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=stolee@gmail.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).