Re: [PATCH] packfile: fix perf regression with many packs

> Le 13 août 2026 à 05:04, Johannes Schindelin <[email protected]> a écrit :
> 
> Hi Ben,
> 
> On Wed, 12 Aug 2026, Ben Knoble wrote:
> 
>>> Le 12 août 2026 à 15:15, Johannes Schindelin via GitGitGadget
>>> <[email protected]> a écrit :
>>> 
>>> [...]
>>>   packfile: fix perf regression with many packs
>>> 
>>>   This issue was spotted by a Microsoft Git user with the massive
>>>   amount of packfiles typical of an average, long-running monorepo
>>>   checkout.
>> 
>> As a different kind of intermediate solution, would turning on
>> maintenance for that user’s checkout help? (Not sure that would help CI
>> clone times unless the server repacks, of course.)
> 
> I should have clarified that the issue is a _Scalar_ clone. And
> specifically a _Microsoft Git Scalar_ clone.
> 
> This matters because, for various reasons that I don't want to elaborate
> on because today I'm in need of lifting up my mood, a substantial part of
> Microsoft Git failed to get upstreamed to core Git.
> 
> One of these is the "shared cache repository", i.e. a bare repository that
> is established as an alternate of the actual clone, and into which the
> actual scheduled fetches go. For full details, see
> https://github.com/microsoft/git/commit/55226d12ed36 (scalar: do
> initialize `gvfs.sharedCache`, 2021-05-03).
> 
> Now, maintenance _does_ run, usually, on that shared cache repository
> (being careful not to inadvertently drop objects merely because they're
> unreachable within the shared cache repository). So theoretically, you're
> right that maintenance should help this issue.
> 
> For reasons (which I don't have the time to find out, but I suspect that
> maintenance simply takes too long and does not finish by the time the
> machine is shut down for the day), it is still not exactly rare to find
> setups with five-digit packfile counts. And since we _can_ handle this
> more gracefully, we should ;-)
> 
> Ciao,
> Johannes

Thanks, very informative!

What I actually meant, sorry if I wasn’t clear, is that maintenance seems likely to help the local (à la PS1) case more than the clone. But maybe it will suffer from the same « takes too long » problem, idk.