Git development
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH] packfile: fix perf regression with many packs
Date: Thu, 13 Aug 2026 12:10:36 -0400	[thread overview]
Message-ID: <20260813161036.GA1386479@coredump.intra.peff.net> (raw)
In-Reply-To: <ed5c651f-648f-f58c-bbd3-3db295515913@gmx.de>

On Thu, Aug 13, 2026 at 10:25:25AM +0200, Johannes Schindelin wrote:

> > > > +test_perf "abbreviate with 10,000 packs" '
> > > > +	git rev-parse --short HEAD
> > > > +'
> > 
> > ...I wonder what value this is adding. It shows the same slowdown as the
> > existing test you can see in the context (and whose results I showed
> > above).
> 
> I do think that there is value in adding this. It not only directly
> reflects what GIT_PS1 runs, but it also exercises a subtly different path:
> `--short` has to look for the unique abbreviation, whereas `--verify` can
> stop as soon as it found the OID already.

Yes, though the regression your patch fixes is about creating the
initial pack list, so it happens whether we open each pack or not.

We do test multiple cases earlier in the file where we look at each
object (both a stock rev-list, and one where we abbreviate, looking for
perf problems in the shortening code itself). But we only do that for
1/50/1000 packs, not the big 10,000 pack case.

I dunno. It probably is not hurting much to have some redundancy in the
tests because this one in particular is not too expensive to run. So I
am OK either way.

-Peff

  reply	other threads:[~2026-08-13 16:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 19:11 [PATCH] packfile: fix perf regression with many packs Johannes Schindelin via GitGitGadget
2026-08-12 19:51 ` Junio C Hamano
2026-08-12 21:29   ` Jeff King
2026-08-13  7:35     ` Patrick Steinhardt
2026-08-13  8:25     ` Johannes Schindelin
2026-08-13 16:10       ` Jeff King [this message]
2026-08-13  8:26   ` Johannes Schindelin
2026-08-12 22:29 ` Ben Knoble
2026-08-13  9:04   ` Johannes Schindelin
2026-08-13 11:18     ` Ben Knoble
2026-08-13  7:35 ` Patrick Steinhardt
2026-08-13  9:20   ` Johannes Schindelin
2026-08-13 10:01     ` Patrick Steinhardt
2026-08-13 10:42       ` [PATCH] packfile: fix perf regression with many packsy Johannes Schindelin
2026-08-13 11:12         ` Patrick Steinhardt
2026-08-13 13:52   ` [PATCH] packfile: fix perf regression with many packs Junio C Hamano
2026-08-13 16:15   ` Jeff King
2026-08-13 14:56 ` [PATCH v2] " Johannes Schindelin via GitGitGadget

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

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

  git send-email \
    --in-reply-to=20260813161036.GA1386479@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=ps@pks.im \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox