From: Jeff King Date: Thu, 04 Jun 2026 07:12:04 GMT Subject: Re: [PATCH v3] index-pack: retain child bases in delta cache Message-ID: <20260604071204.GA3196596@coredump.intra.peff.net> In-Reply-To: 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