Re: Performance problem with GC enabled
Re: Performance problem with GC enabled
- Subject: Re: Performance problem with GC enabled
- From: John Engelhart <email@hidden>
- Date: Fri, 13 Mar 2009 22:59:11 -0400
On Fri, Mar 13, 2009 at 8:26 PM, Peter Ammon <email@hidden> wrote:
>
> On Mar 13, 2009, at 4:47 PM, John Engelhart wrote:
>
>> On Thu, Mar 12, 2009 at 3:17 PM, Peter Ammon <email@hidden> wrote:
>>>
>>> Hi John,
>>>
>>> Instead of storing each string individually into the heap, try batching
>>> up,
>>> say, 1k or so into a stack allocated buffer. Then use
>>> objc_memmove_collectable() to move them in bulk into the heap at the
>>> point
>>> your stack allocated buffer gets full, or your scan finishes.
>>>
>>
>> I actually did give this a shot, or something close to it. I tried
>> using just the stack (swapping NSAllocateCollectable() with alloca()),
>> but no joy- exactly the same times came out. Good call though.
>>
>
> That wasn't quite my suggestion, and I would not expect that to result in
> any improvement. If you store an object through an arbitrary pointer, the
> compiler will use a write barrier. I doubt the compiler will figure out
> that because the memory came from alloca(), it is on the stack.
Huh.. I have to say, my first response would have been that the
compiler would definitely figure it out, but that's a topic for a
different conversation. (it has to do with just how tightly integrated
alloca() is to the compiler internals, see
http://c-faq.com/malloc/alloca.html for a rough idea why)
> The goal is for the compiler to not use individual write barriers at all,
> and it won't for stack allocated buffers. So my suggestion is to make a
> buffer that the compiler knows is on the stack:
>
> id stackBuffer[1024];
>
> Stores to that buffer will not go through write barriers. When that buffer
> is full, use objc_memmove_collectable() to move it to the heap.
>
> I wrote a quick test to try this and it resulted in a 10x speedup compared
> to individual write barriers.
Ok, now I see where you're going. I'll certainly give it a whirl, but
it's going to make swiss cheese out of the code with #ifdef
__OBJC_GC__ statements, unfortunately. (the code needs to work with or
without GC (w/o -fobjc-gc*), and with or without -std=(c|gnu)99 and
thus the use of alloca(), not VLAs).
Thanks for the suggestion. Hmmm, that does raise the obvious
question of "Does objc_memmove_collectable() hold the GC lock the
entire time it's doing its thing?" If so, it'll probably make some
sense to find that sweet spot where you hit the point of diminishing
returns so you keep the lock for as short a time as possible.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden