Jeff King <p...@peff.net> writes:
> Thanks, this writeup makes sense to me. Obviously,
> Signed-off-by: Jeff King <p...@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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html