Re: Threads & communication performance
Re: Threads & communication performance
- Subject: Re: Threads & communication performance
- From: Jean-Francois Roy <email@hidden>
- Date: Tue, 09 Aug 2005 04:08:24 -0400
I've had a similar problem in the past. No solution is universal as
usual, but in my case it was elegant to make the UI thread
responsible for updating itself.
The theory is that a human being will perceive a long process or
computation as ongoing normally if some form of feedback is provided
every so often, along the lines of every 1 to 5 seconds. It is
generally useless, and in fact quite wasteful, to update the UI every
0.1 seconds for instance.
The solution involved setting up a timer to refresh the UI every n
seconds (the frequency is totally up to you) and either a mutex or an
atomically tested and changed global flag to block the computation
thread when the UI thread wants to update.
If it is memory efficient and not too disruptive, you can even cache
certain pieces of information in "UI variables" and access them
without any kind of exclusive access scheme. For instance, an overall
progress indicator variable (say a double with values from 0.0 to 1.0
to indicate the completion of the computations) can be written by the
computation thread and read by the UI thread without any mutex of any
sort protecting it, since at worst the UI will simply "skip" an
update for once update cycle.
And as always, Shark It™
On Aug 8, 2005, at 23:49, Laurent Michel wrote:
On Aug 8, 2005, at 11:33 PM, Scott Ribe wrote:
Any advice ? Suggestions ?
As previously suggested, decouple drawing from calculation. You
may think
the app felt sluggish at 35fps, but there's simply no way a human can
perceive the individual changes even at that rate...
I am not after a high FPS per se. This was just another symptom/
observation that I did correlate with the odd low CPU usage
(pauses). Shaun provided me with a good explanation of the cause
for these pauses. Now I will have to streamline the communication
to eliminate the bottleneck that causes the pauses (I am flooding
the message queue of the Cocoa thread which induces blocking waits
until the queue is at least partially emptied by the UI thread).
Solution: re-architect to avoid that message flood.
--
Scott Ribe
email@hidden
http://www.killerbytes.com/
(303) 665-7007 voice
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40macstorm.org
This email sent to email@hidden
Jean-Francois Roy
--
Co-Founder of MacStorm
Programmer at MacStorm
http://www.macstorm.org
email@hidden
http://www.macstorm.org/bahamut/Jean-Francois.gpgkey
Attachment:
PGP.sig
Description: This is a digitally signed message part
_______________________________________________
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