All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Justin Tobler <jltobler@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/7] odb/source-packed: improve lookup when enumerating objects
Date: Fri, 10 Jul 2026 09:08:34 +0200	[thread overview]
Message-ID: <alCacqAl9gItMKo7@pks.im> (raw)
In-Reply-To: <ak_uXc0UxB_9Vk9z@denethor>

On Thu, Jul 09, 2026 at 02:54:17PM -0500, Justin Tobler wrote:
> On 26/07/09 10:35AM, Patrick Steinhardt wrote:
> > When iterating through packed objects via `odb_for_each_object()` we
> > do so via two different mechanisms:
> > 
> >   - When a multi-pack index is available we use that one to efficiently
> >     loop through all objects.
> > 
> >   - We then loop through all packfiles that aren't covered by a
> >     multi-pack index.
> 
> To be specific, we are talking only about the for_each_object callback
> for the packed source `odb_source_packed_for_each_object()` correct?
> Also, this appears to only matter when we are enumerating OIDs with a
> specific prefix.

Yeah, true. I'll clarify this a bit.

> > Regardless of which mechanism we use, we then iterate through all the
> > objects indexed by the respective data structure. Curiously though,
> > while we use the indices for enumerating the objects, we completely
> > ignore it for the actual object lookup. Instead, we call into the
> > generic `odb_source_read_object_info()` function, which will itself
> > consult the indices to figure out where the object in question even
> > lives.
> > 
> > This has two consequences:
> > 
> >   - It's inefficient, as we basically have to figure out the position of
> >     the object a second time.
> 
> Since we already have the position from the index, there is no need to
> start over. Makes sense.
> 
> >   - It's subtly wrong, as it may now happen that a specific object will
> >     be looked up via a different pack in case it exists multiple times.
> 
> Naive question: Is there any real harm in reading the same object, but
> from a different packfile here?

The answer is probably "no". At least I cannot think of any case where
it'd really matter, but semantically it's the wrong thing to do anyway.

> > diff --git a/odb/source-packed.c b/odb/source-packed.c
> > index 0edea5356d..9cfa02b7a2 100644
> > --- a/odb/source-packed.c
> > +++ b/odb/source-packed.c
> > @@ -177,9 +178,8 @@ static int for_each_prefixed_object_in_midx(
> >  			if (!match_hash(len, opts->prefix->hash, current->hash))
> >  				break;
> >  
> > -			if (opts->flags) {
> > +			if (opts->flags || data->request) {
> 
> I'm not sure I follow why the above condition needed to change.

This needs to change because we now require access to the pack so that
we can call `packed_object_info()`. Otherwise the pack would be not be
populated if we're invoked without any flags.

Patrick

  reply	other threads:[~2026-07-10  7:08 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09  8:35 [PATCH 0/7] odb: introduce object filters to `odb_for_each_object()` Patrick Steinhardt
2026-07-09  8:35 ` [PATCH 1/7] odb/source-packed: improve lookup when enumerating objects Patrick Steinhardt
2026-07-09 19:54   ` Justin Tobler
2026-07-10  7:08     ` Patrick Steinhardt [this message]
2026-07-09  8:35 ` [PATCH 2/7] pack-bitmap: mark object filter as `const` Patrick Steinhardt
2026-07-09  8:35 ` [PATCH 3/7] pack-bitmap: allow aborting iteration of bitmapped objects Patrick Steinhardt
2026-07-09 20:19   ` Justin Tobler
2026-07-10  7:08     ` Patrick Steinhardt
2026-07-11  7:47       ` Jeff King
2026-07-09  8:35 ` [PATCH 4/7] pack-bitmap: iterate object sources when opening bitmaps Patrick Steinhardt
2026-07-09 21:08   ` Justin Tobler
2026-07-10  7:08     ` Patrick Steinhardt
2026-07-09  8:35 ` [PATCH 5/7] pack-bitmap: introduce function to open bitmap for a single source Patrick Steinhardt
2026-07-09  8:35 ` [PATCH 6/7] odb: introduce object filters to `odb_for_each_object()` Patrick Steinhardt
2026-07-09 21:43   ` Justin Tobler
2026-07-10  7:09     ` Patrick Steinhardt
2026-07-09  8:35 ` [PATCH 7/7] builtin/cat-file: filter objects via object database Patrick Steinhardt
2026-07-09 18:59   ` Junio C Hamano
2026-07-10  7:09     ` Patrick Steinhardt
2026-07-10  8:48 ` [PATCH v2 0/8] odb: introduce object filters to `odb_for_each_object()` Patrick Steinhardt
2026-07-10  8:48   ` [PATCH v2 1/8] odb/source-packed: improve lookup when enumerating objects Patrick Steinhardt
2026-07-10 22:25     ` Taylor Blau
2026-07-13  9:54       ` Patrick Steinhardt
2026-07-14  3:49         ` Taylor Blau
2026-07-14  5:35           ` Patrick Steinhardt
2026-07-10  8:48   ` [PATCH v2 2/8] pack-bitmap: mark object filter as `const` Patrick Steinhardt
2026-07-10 22:25     ` Taylor Blau
2026-07-10  8:48   ` [PATCH v2 3/8] pack-bitmap: allow aborting iteration of bitmapped objects Patrick Steinhardt
2026-07-10 22:34     ` Taylor Blau
2026-07-11  8:01       ` Jeff King
2026-07-13  9:53         ` Patrick Steinhardt
2026-07-14  3:58           ` Taylor Blau
2026-07-14  7:17             ` Jeff King
2026-07-10  8:48   ` [PATCH v2 4/8] pack-bitmap: iterate object sources when opening bitmaps Patrick Steinhardt
2026-07-10 22:40     ` Taylor Blau
2026-07-10  8:48   ` [PATCH v2 5/8] pack-bitmap: drop `_1` suffix from functions that open bitmaps Patrick Steinhardt
2026-07-10 22:41     ` Taylor Blau
2026-07-10  8:48   ` [PATCH v2 6/8] pack-bitmap: introduce function to open bitmap for a single source Patrick Steinhardt
2026-07-10  8:48   ` [PATCH v2 7/8] odb: introduce object filters to `odb_for_each_object()` Patrick Steinhardt
2026-07-10 22:42     ` Taylor Blau
2026-07-10  8:49   ` [PATCH v2 8/8] builtin/cat-file: filter objects via object database Patrick Steinhardt
2026-07-11  7:58   ` [PATCH v2 9/8?] pack-objects: drop unused return value from add_object_entry() Jeff King
2026-07-11 16:42     ` Junio C Hamano
2026-07-13 14:41 ` [PATCH v3 0/9] odb: introduce object filters to `odb_for_each_object()` Patrick Steinhardt
2026-07-13 14:41   ` [PATCH v3 1/9] odb/source-packed: improve lookup when enumerating objects Patrick Steinhardt
2026-07-13 14:41   ` [PATCH v3 2/9] pack-bitmap: mark object filter as `const` Patrick Steinhardt
2026-07-13 14:41   ` [PATCH v3 3/9] pack-objects: drop unused return value from add_object_entry() Patrick Steinhardt
2026-07-13 14:41   ` [PATCH v3 4/9] pack-bitmap: allow aborting iteration of bitmapped objects Patrick Steinhardt
2026-07-13 14:41   ` [PATCH v3 5/9] pack-bitmap: iterate object sources when opening bitmaps Patrick Steinhardt
2026-07-13 14:41   ` [PATCH v3 6/9] pack-bitmap: drop `_1` suffix from functions that open bitmaps Patrick Steinhardt
2026-07-13 14:41   ` [PATCH v3 7/9] pack-bitmap: introduce function to open bitmap for a single source Patrick Steinhardt
2026-07-13 14:41   ` [PATCH v3 8/9] odb: introduce object filters to `odb_for_each_object()` Patrick Steinhardt
2026-07-13 14:41   ` [PATCH v3 9/9] builtin/cat-file: filter objects via object database Patrick Steinhardt
2026-07-14  3:59   ` [PATCH v3 0/9] odb: introduce object filters to `odb_for_each_object()` Taylor Blau
2026-07-14  5:36     ` Patrick Steinhardt
2026-07-14  7:17   ` 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=alCacqAl9gItMKo7@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=jltobler@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.