From: Ramsay Jones <ramsay@ramsay1•demon.co.uk>
To: Jeff King <peff@peff•net>
Cc: Junio C Hamano <gitster@pobox•com>,
GIT Mailing-list <git@vger•kernel.org>
Subject: Re: [PATCH 2/7] move setting of object->type to alloc_* functions
Date: Mon, 14 Jul 2014 12:03:17 +0100 [thread overview]
Message-ID: <53C3B8F5.5000702@ramsay1.demon.co.uk> (raw)
In-Reply-To: <20140714055727.GA5593@sigill.intra.peff.net>
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
next prev parent reply other threads:[~2014-07-14 11:03 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-10 23:59 [PATCH v3 2/2] alloc.c: remove the redundant commit_count variable Ramsay Jones
2014-07-11 0:30 ` Jeff King
2014-07-11 0:59 ` Ramsay Jones
2014-07-11 8:32 ` Jeff King
2014-07-11 9:41 ` Ramsay Jones
2014-07-11 8:41 ` [PATCH 0/7] ensure index is set for all OBJ_COMMIT objects variable Jeff King
2014-07-11 8:42 ` [PATCH 1/7] alloc.c: remove the alloc_raw_commit_node() function Jeff King
2014-07-11 8:46 ` [PATCH 2/7] move setting of object->type to alloc_* functions Jeff King
2014-07-12 14:44 ` Ramsay Jones
2014-07-12 18:05 ` Jeff King
2014-07-13 6:41 ` Jeff King
2014-07-13 6:41 ` [PATCH v2 1/8] alloc.c: remove the alloc_raw_commit_node() function Jeff King
2014-07-15 20:06 ` Junio C Hamano
2014-07-13 6:41 ` [PATCH v2 2/8] alloc: write out allocator definitions Jeff King
2014-07-15 20:11 ` Junio C Hamano
2014-07-13 6:41 ` [PATCH v2 3/8] move setting of object->type to alloc_* functions Jeff King
2014-07-15 20:12 ` Junio C Hamano
2014-07-13 6:42 ` [PATCH v2 4/8] parse_object_buffer: do not set object type Jeff King
2014-07-13 6:42 ` [PATCH v2 5/8] add object_as_type helper for casting objects Jeff King
2014-07-13 6:42 ` [PATCH v2 6/8] alloc: factor out commit index Jeff King
2014-07-13 6:42 ` [PATCH v2 7/8] object_as_type: set " Jeff King
2014-07-13 6:42 ` [PATCH v2 8/8] diff-tree: avoid lookup_unknown_object Jeff King
2014-07-13 19:27 ` [PATCH 2/7] move setting of object->type to alloc_* functions Ramsay Jones
2014-07-14 5:57 ` Jeff King
2014-07-14 11:03 ` Ramsay Jones [this message]
2014-07-12 14:55 ` Ramsay Jones
2014-07-12 18:07 ` Jeff King
2014-07-11 8:46 ` [PATCH 3/7] parse_object_buffer: do not set object type Jeff King
2014-07-11 8:48 ` [PATCH 4/7] add object_as_type helper for casting objects Jeff King
2014-07-11 10:45 ` Ramsay Jones
2014-07-11 16:59 ` Jeff King
2014-07-11 8:48 ` [PATCH 5/7] alloc: factor out commit index Jeff King
2014-07-11 8:49 ` [PATCH 6/7] object_as_type: set " Jeff King
2014-07-11 8:50 ` [PATCH 7/7] diff-tree: avoid lookup_unknown_object Jeff King
2014-07-11 10:31 ` [PATCH 0/7] ensure index is set for all OBJ_COMMIT objects variable Ramsay Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53C3B8F5.5000702@ramsay1.demon.co.uk \
--to=ramsay@ramsay1$(echo .)demon.co.uk \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox