Re: [PATCH 00/20] Separate `ref_cache` into a separate module
From: Jeff King <hidden>
Date: 2017-03-20 18:14:30
On Mon, Mar 20, 2017 at 05:33:05PM +0100, Michael Haggerty 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.
Having played a bit with the work-in-progress, I'm very excited about the performance improvements.
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