Re: [PATCH 00/20] Separate `ref_cache` into a separate module

From: Jeff King <peff@peff.net>
Date: Mar 20, 2017, 18:30 UTC
Message-ID: <20170320183022.mlv2y5g6pn2i7znq@sigill.intra.peff.net>
In-Reply-To: <CACBZZX7Kqo=w-c2LOH9a4xf6WpnhE5tsvNHa1O2-4dvYTKZxEA@mail.gmail.com>

On Mon, Mar 20, 2017 at 07:24:12PM +0100, Ævar Arnfjörð Bjarmason wrote:

Show 12 quoted lines

> On Mon, Mar 20, 2017 at 5:33 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> 
> > I've completed a draft of an epic 48-patch series implementing all of
> > the above points on my GitHub fork [1] as branch
> > `wip/mmap-packed-refs`. It dramatically speeds up performance and
> > reduces memory usage for some tasks in repositories with very many
> > packed references.
> 
> Just curious, what sort of performance numbers on mainly what sort of
> operations? I'd expect the fixed cost of e.g. `git log -1 >/dev/null`
> to go down, which can take as long as a second on some repos with a
> huge amount of refs, but anything else?

Anything that reads refs (and that includes anything that touches an object, because it looks at refs/replace) loads the entire packed-refs file into memory. So I'd expect you're paying that "1 second" cost on a lot of commands.

Even commands that traverse the entire ref namespace should improve, as we'd spend a lot less time allocating and copying data into the in-memory refs cache. Not to mention that the memory usage is reduced, though that probably only really matters for pathological cases.

-Peff