Re: [PATCH 2/7] move setting of object->type to alloc_* functions

[Jeff King <peff@peff.net>]

On Sun, Jul 13, 2014 at 08:27:51PM +0100, Ramsay Jones wrote:

> > Thinking on this more, writing out the definitions is the only sane
> > thing to do here, now that alloc_commit_node does not use the macro.
> > Otherwise you are inviting people to modify the macro, but fail to
> > notice that the commit allocator also needs updating.
> 
> Hmm, well I could argue that using the macro for all allocators, apart
> from alloc_commit_node(), clearly shows which allocator is the odd-man
> out (and conversely, that all others are the same)! :-P
> 
> No, I don't think this is a telling advantage; I don't think it makes
> that much difference. (six of one, half-a-dozen of the other).

Yeah, I agree with your final statement in parentheses. I am OK with it
either way (but I have a slight preference for what I posted).

> I was slightly concerned, when reading through this new series, that the
> alloc_node() function may no longer be inlined in the new allocators.
> However, I have just tested on Linux (only using gcc this time), and it
> was just fine. I will test the new series on the above systems later
> (probably tomorrow) but don't expect to find any problems.

That should not be due to my patches (which are just expanding macros),
but rather to your 1/8, right?

I do not know that it matters that much anyway. Yes, we allocate a lot
of objects in some workloads. But I think it is not so tight a loop that
the extra function call is going to kill us (and we tend to _read_ the
allocated objects much more than we allocate them).

> > Here's a re-roll. The interesting bit is the addition of the second
> > patch (but the rest needed to be rebased on top).
> 
> Yep, this looks good. Thanks!

Thanks for reviewing, as usual.

-Peff