Re: Performance regression in connectivity check during receive-pack (git 2.54)

On Tue, Jul 21, 2026 at 07:40:02AM -0700, Junio C Hamano wrote:
> Jeff King <[email protected]> writes:
> 
> > Yeah, and that type of regression makes sense for what a593373b09 was
> > trying to do. But I think the v2.54 behavior is wrong. We should check
> > all packs before any loose objects.
> >
> > I'm not sure of the correct fix. This is working against the whole "odb
> > sources are independent and abstract" refactoring that a593373b09 was
> > going for. But I think it's an important optimization. I guess the
> > abstract version would be that each source has "fast" and "slow" lookups
> > or something like that, and we check all fast ones before slow ones. But
> > that is pretty gross.
> >
> > I'll leave it to Patrick to ponder further. I haven't really been paying
> > a lot of attention to the odb refactoring.
> 
> I think checking the fast sources before the slow ones is probably
> the best we can do if we want to retain the 'each odb source is an
> opaque object' abstraction.

Seeing that this is about the `tmp_objdir` case: one of the things that
Justin and I wanted to work on anyway is that we want to stop modifying
the list of sources during transactions in the first place. It always
felt kind of gross that we're modifying the sources when creating a
transaction, as the only reason that we do this for is so that the
writes actually go to the temporary object directory instead of to the
primary object source. And that doesn't make a lot of sense to begin
with.

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'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.

Patrick