Re: [PATCH 0/7] nd/repack-keep-pack update

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Apr 14, 2018, 19:47 UTC
Message-ID: <878t9pfu4f.fsf@evledraar.gmail.com>
In-Reply-To: <20180414152642.4666-1-pclouds@gmail.com>

On Sat, Apr 14 2018, Nguyễn Thái Ngọc Duy wrote:

> This is basically a resend from the last round but rebased on
> 'master'. The old base results in some conflicts with packfile and oid
> conversion series. This one should reduce merge conflicts on 'pu' to
> trivial ones.

Thanks. I've been running this at work and as noted in https://public-inbox.org/git/87vadpxv27.fsf@evledraar.gmail.com/ it's had big performance impact to the better, users even started noticing it (they'd previously get noticeable slowdowns while doing other task on GC).

I also tried to see just how much worse this was making performance, my hunch was that the difference should be trivial but noticeable since we'll produce a less efficient pack.

What I found was the opposite, under real-world conditions it seems to be making things 1-2% better on common git operations, which I suspect is because once we've done a few pulls and coalesced those into their own pack(s) there's more cache locality for the data we're actually looking at.

I.e. once you've got a repo has a big pack you're not touching, and a few weeks of updates from upstream that you've coalesced into another pack there's a higher density of stuff you care about near HEAD per FS page in the recent smaller pack, which if you're pressed for memory and parts of your pack are getting paged out of the FS cache is a win. I haven't confirmed that, it's just a hypothesis.

The only (trivial) issue I found in the patches themselves was that between 4/5 and 5/7 you're adding an empty line to config.txt in 4/7 just to erase it in 5/7, better not to add it to begin with, but hopefully Junio can fix that up (if he cares).