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: Sat, 14 Mar 2009 18:22:58 -0400
On Fri, Mar 13, 2009 at 11:21 PM, Peter Ammon <email@hidden> wrote:
>
> 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.
This particular idea did occur to me, but I choose not to pursue it.
The reason for this is because it's for RegexKitLite
(http://regexkit.sourceforge.net/RegexKitLite/index.html). This is
compiled directly by the end user, under a wide variety of conditions,
so I have to err on the side of 'correctness'. I made a judgement
call that this one (tricking the compiler with void *) cut it just a
bit too close.
Your objc_memmove suggestion, however, is pretty elegant. If the
compiler chooses not to emit write barriers when storing to an 'id
strings[1024];' local variable, well.. I've met all my obligations
regarding strong pointers, now, and in the future, without hiding the
strong nature of the pointer from the compiler. This should be able
to correctly handle any future GC changes as well, which is important.
Strikes a good balance between being 'correct' while taking advantage
of 'observed implementation details'.
Again, thanks for the suggestion. It's pretty clever and elegant,
even if it does make swiss cheese of the code with #ifdef statements.
:)
_______________________________________________
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