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

From: Jeff King <peff@peff.net>
Date: Mar 20, 2017, 18:12 UTC
Message-ID: <20170320181244.h5ce4rbadkharnki@sigill.intra.peff.net>
In-Reply-To: <cover.1490026594.git.mhagger@alum.mit.edu>

On Mon, Mar 20, 2017 at 05:33:05PM +0100, Michael Haggerty wrote:

Show 5 quoted lines

> 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.

Having played a bit with the work-in-progress, I'm very excited about the performance improvements.

Show 8 quoted lines

> But the later parts of that series aren't completely polished yet, and
> such a large patch series would be indigestible anyway, so here I
> submit the first part...
> 
> This patch series extracts a `ref_cache` module out of
> `files_ref_cache`, and goes some way to disentangling those two
> modules, which until now were overly intimate with each other:
> [...]

I just read through it and didn't see anything objectionable. I had a few questions, but I expect that most can be answered with an explanation rather than a re-roll.

> Even after this patch series, the modules are still too intimate for
> my taste, but I think this is a big step forward, and it is enough to
> allow the other changes that I've been working on.

The resulting code looks like a big improvement in modularity to me. My one complaint is that the virtual functions make it hard to dig through the code. E.g., when looking at one patch I saw that we called ref_iterator_peel(), and I wanted to know what that entailed. My editor helpfully jumps straight to the definition, but of course it has nothing useful; it's just a vtable wrapper. And I had to go dig up the name "files_peel_ref()" manually.

I guess that's the price we pay for modularity.

-Peff