Thread (32 messages) 32 messages, 3 authors, 2017-03-22

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help