Re: Threads & communication performance
Re: Threads & communication performance
- Subject: Re: Threads & communication performance
- From: Laurent Michel <email@hidden>
- Date: Mon, 8 Aug 2005 21:34:45 -0400
An interesting observation I just made....
I remember reading hints about the 'virtues' (performance wise) of
disabling beam-sync through the Quartz Debug tools... So I went ahead
and did this....
Before disabling: The refresh were coming through at a rate of
~35FPS. The application 'felt' sluggish and took 1m10s to complete
the same task as the batch version (which does its job in 10s)
After disabling: Refresh rate solid at > 90FPS (the gauge maxed out).
The two CPUS are quite busy. Not full use, but way more that 10% and
a total running time of 14s!!!!
So... Beam-sync seems to be causing the 'problem'/'pause'.
Now I understand (and saw) that beam-sync is there to prevent
horizontal shearing when dragging windows. But still, the window here
isn't dragged around and I really wonder what I could do to regain
the performance I expect without disabling beam-sync....
Any advice ? Suggestions ?
On Aug 8, 2005, at 8:01 PM, Shaun Wexler wrote:
On Aug 8, 2005, at 3:16 PM, Laurent Michel wrote:
I have a behavior in my application that is somewhat disappointing
and puzzling. In a nutshell, the application has two threads, one
is a Cocoa thread and manages the UI, the other is compute-bound.
The compute bound thread wishes to send 'updates' to the UI thread
regularly (when events of interest occurs).
You are using a high-overhead approach which also tightly couples
and effectively single-threads the process. You need to uncouple
the GUI from the calculations, and minimize your cross-thread
messaging. There are many more efficient ways to do this, but for
brevity this should serve as an example:
#include <std_mail_disclaimer.h>
static UInt32 dataDirty __attribute__ ((aligned (4))) = 0;
- (void)calculationThread:(id)someObject
{
while ([self hasWorkToDo])
{
[self performOneIterationOfWork];
if (CompareAndSwap(0, 1, &dataDirty)) {
NSData *data = [self copyDataForDisplay];
[self performSelectorOnMainThread:@selector
(updateData:) withObject:data waitUntilDone:NO];
}
}
}
- (void)updateData:(NSData *)data
{
[matrixController setMatrixWithCalculatedData:data];
[matrix displayIfNeeded];
CompareAndSwap(1, 0, &dataDirty);
[data release];
}
If you use a custom matrix, you can add another atomic flag to -
drawRect: and nearly eliminate all subsequent cross-thread perform
messages, and Tiger will nicely limit drawing rate to max refresh
for you.
HTH~
--
Shaun Wexler
MacFOH
http://www.macfoh.com
Efficiency is intelligent laziness.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden