Subject: Re: [PATCH v3] index-pack: retain child bases in delta cache

From: Jeff King <[email-masked]>
Date: Thu, 4 Jun 2026 03:12:04 -0400

On Wed, Jun 03, 2026 at 12:05:17AM +0000, Arijit Banerjee via GitGitGadget wrote:

>      * Addressed Jeff King's review question by releasing cached base data
>        after all direct children have been dispatched, while keeping the
>        existing subtree bookkeeping intact.
>      * Re-ran t/t5302-pack-index.sh, p5302-pack-index.sh, and end-to-end
>        full clone spot checks with the precise-release version.

Thanks for humoring me. I fully expected the answer to be "it is hard to
do and doesn't show much improvement, so let's not bother". ;)

It was hard to see the difference between v2 and v3 performance (which I
tried to dig out from the range-diff below), but it looks like it was
basically none. I did my own run of p5302 between the two versions using
both git.git and linux.git, and likewise didn't find anything.

I guess it would make a difference only if we were routinely expiring
useful items out of the cache due to the limit. And even though
linux.git is a "large" repo compared to git.git, cache locality here is
mostly based on how wide the delta tree for a file gets (that is, how
often we go down one chain, caching bases, while still finding it useful
to keep earlier parts of the chain to go down a parallel path).

And that probably has less to do with overall repo size rather than with
how we tend to pack things. Though I guess a repo with a lot of large
files might see more cache pressure (just because each single entry
"costs" more). We could simulate that by dropping the cache size in
p5302, but I still couldn't find any effect even with a tiny cache.

(Actually, with a tiny cache it looked like things got ~1% slower; maybe
noise, but maybe extra thread contention due to the release code?).

So I am happy with either v2 or v3.

-Peff