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:18:17 -0400
On Fri, Mar 13, 2009 at 4:38 AM, Marcel Weiher <email@hidden> wrote:
>
> On Mar 12, 2009, at 10:54 AM, Bill Bumgarner wrote:
>>
>> In the context of an application, such processing is likely to be on a
>> secondary thread and there is likely to be synchronization of data between
>> threads.
>> The overhead of the write barrier (which is spin lock contention under
>> the covers, most likely) will be somewhat offset by the vast decrease in the
>> cost of moving objects between threads, for example.
>
> The synchronization overhead for moving progress updates across threads
> every 10th of a second is negligible unless you're doing something very very
> wrong.
I have to agree with Marcel on this. In fact, in such a scenario, I'm
almost certainly going to be using OSAtomicEnqueue and
OSAtomicDequeue. I'm willing to guarantee that this will outperform a
call to objc_assign_strongCast by several orders of magnitude, so much
so that it would actually be an incentive to turn off GC. It has the
added advantage of never causing the background worker threads to
block while waiting for a spin lock.
Come to think of it, I'm not even sure how you could write a GC
enabled multi-threaded app that uses one thread per CPU to split work
up. All your background threads are going to come to a grinding halt
as they serialize inside objc_assign_strongCast.
>> Sure -- and if I were writing a Cocoa application to do exactly that, it
>> would be doing all kinds of UI updates during the process to keep the user
>> up to date on progress, give them a feel for whether the analysis is moving
>> along in the correct direction, etc,etc,etc.... and all of that graphics
>> related chatter is very likely going to far outweigh the CPU cycles consumed
>> by the actual data processing bit.
>
> Not if you're doing it right.
Again, I have to agree with Marcel on this. In fact I'd say, as a
rough rule of thumb, if shark is telling you that you're spending more
than 5% of your time doing UI updates, you're doing something wrong.
If you have something that takes 5 minutes to process without any kind
of UI updates, and your GUI versions interface updates now 'far
outweigh the CPU cycles consumed' (>50%) relative to the data
processing, you've now turned something that takes 5 minutes in to 10+
minutes. I can't say I understand why you think this is reasonable,
or even the norm.
_______________________________________________
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