On 14/07/14 06:57, Jeff King wrote:
> 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).
Yep, once again, this looks good to me. :-)
>> 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?
Ah, no. Over the years, I've used many compilers which would happily
inline this:
void *alloc_blob_node(void)
{
return alloc_node(&blob_state, sizeof(struct blob));
}
but not this:
void *alloc_blob_node(void)
{
struct blob *b = alloc_node(&blob_state, sizeof(struct blob));
return b;
}
Admittedly, it has been many years since I've had to use such a compiler,
but old habits die hard and I always check! (The compiler is not obliged
to inline the code anyway).
> 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).
Yes, my testing indicates that it wouldn't be noticeable if it wasn't
inlined, at least on my git.git repo. (The largest repo I have is an
ffmpeg repo, which is only about twice the size of git.git; but I used
git.git for the timing/profiling tests). So, I'm always slightly nervous
about affecting users of really large repos.
I don't think it will be an issue either way (famous last words!). ;-)
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html