Re: Performance problem with GC enabled
Re: Performance problem with GC enabled
- Subject: Re: Performance problem with GC enabled
- From: Peter Ammon <email@hidden>
- Date: Fri, 13 Mar 2009 20:21:37 -0700
On Mar 13, 2009, at 7:59 PM, John Engelhart wrote:
On Fri, Mar 13, 2009 at 8:26 PM, Peter Ammon <email@hidden> wrote:
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).
I think you're saying that it's more convenient for you to work with a
pointer than directly with an array. If so, another way you can
defeat write barriers is with a cast to void*:
void func(id *ptr) {
ptr[0] = @"foo"; // <--- write barrier
((void **)ptr)[0] = @"bar"; // <---- no write barrier
}
Of course, this is only safe if the pointer points at something not in
the GC heap, e.g. on the stack or in malloc()ed memory. If you store
into the GC heap this way, your object is likely to be prematurely
collected.
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.
I believe it does hold the lock the entire time in Leopard.
-Peter
_______________________________________________
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