Re: [PATCH v3] index-pack: retain child bases in delta cache
- From
Jeff King <peff@peff.net>
- Date
- Jun 4, 2026, 07:12 UTC
- Message-ID
- <20260604071204.GA3196596@coredump.intra.peff.net>
- In-Reply-To
- <pull.2131.v3.git.1780445118653.gitgitgadget@gmail.com>
On Wed, Jun 03, 2026 at 12:05:17AM +0000, Arijit Banerjee via GitGitGadget wrote:
Show 5 quoted lines
> * 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