Re: [PATCH 1/3] commit: allow associating auxiliary info on-demand

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 14, 2013, 19:01 UTC
Message-ID: <7vfvyt543i.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130414151229.GA1544@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 12 quoted lines

> Thanks, this writeup makes sense to me. Obviously,
>
>   Signed-off-by: Jeff King <peff@peff.net>
>
> Comparing a slab index versus a util pointer, I think the differences
> should be:
> ...
> So I think the util pointer is strictly better, except for point (2). And
> the main cost is point (1), the extra indirection. So if we can measure
> (1) and decide it isn't a big cost, the maintainability improvement for
> (2) is probably worth it, and we can rip out the util pointer entirely,
> saving us some extra space in "struct commit".

I am glad you brought up "util". In an earlier round of the indgree thing, I think that it was discussed that casting the indegree to (void *) and storing it there was a possibility. Because sorting was so generic a thing everybody may want in their codepath, and some callers may already have something they want to keep in util, we ended up adding a separate field not to interfere with the callers' use of the util field.

In the simpler days, a single util used with careful coorination among various codepaths may have been manageable, but I tend to think it will become more and more cumbersome to extend the system correctly (the same can be said for the in-object flags). We should encourage the users of the util field to migrate to either slab or decorate in the longer term.

A criterion to choose between the two is probably the density. The slab mechanism is for annotations that almost everybody involved in the processing gets, while decorate is more suited for sparse ones.