Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Jeff King <peff@peff.net>,
	 Wolfgang Kritzinger <wkritzinger@atlassian.com>,
	 git@vger.kernel.org,  jltobler@gmail.com
Subject: Re: Performance regression in connectivity check during receive-pack (git 2.54)
Date: Wed, 22 Jul 2026 08:49:50 -0700	[thread overview]
Message-ID: <xmqqh5lrrplt.fsf@gitster.g> (raw)
In-Reply-To: <amCuLpT6vYzo1GF8@pks.im> (Patrick Steinhardt's message of "Wed, 22 Jul 2026 13:49:02 +0200")

Patrick Steinhardt <ps@pks.im> writes:

> The alternative to this would be to instead have logic in functions like
> `odb_write()` that checks whether we have an active transaction or not.
> If so, the write would go into the transaction directly instead of going
> into the primary source, and consequently we wouldn't even have to
> modify the list of sources at all.
>
> This shouldn't create too much of a problem, as we typically don't
> intend to even read objects that we've written into the transaction
> immediately. It would avoid that we try to read objects from the
> temporary object directory. And it would also allow us to eventually
> move all the logic to write objects into the transactions exclusively.

I suspect several of those 'transactions' are actually misspelt
'temporary directories', but I catch your drift.  That said, a
redesign like that feels more or less independent of the fix for our
immediate performance regression.

After all, didn't Peff show us a case where no odb sources were
being flipped in the middle?  Simply setting up one object store to
borrow from another via the alternates mechanism demonstrated that
checking packs across all object stores before hunting for loose
objects in any of them makes a world of difference.

> I'm currently out of office though, and will be on vacation next week.
> I'll explore this area a bit more though once I'm back in office in two
> weeks.

Understood.  Bon voyage and have fun!


  reply	other threads:[~2026-07-22 15:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-21  3:17 Performance regression in connectivity check during receive-pack (git 2.54) Wolfgang Kritzinger
2026-07-21  3:57 ` Jeff King
2026-07-21  5:05   ` Taylor Blau
2026-07-21 14:40   ` Junio C Hamano
2026-07-22 11:49     ` Patrick Steinhardt
2026-07-22 15:49       ` Junio C Hamano [this message]
     [not found]         ` <20260723104943.GC604358@coredump.intra.peff.net>
2026-07-24  3:46           ` Patrick Steinhardt
2026-07-26  8:51             ` Jeff King

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=xmqqh5lrrplt.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jltobler@gmail.com \
    --cc=peff@peff.net \
    --cc=ps@pks.im \
    --cc=wkritzinger@atlassian.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox