Re: objective-c / cocoa efficiency
Re: objective-c / cocoa efficiency
- Subject: Re: objective-c / cocoa efficiency
- From: Shawn Erickson <email@hidden>
- Date: Tue, 8 Mar 2005 15:24:32 -0800
On Mar 8, 2005, at 2:18 PM, Barton J. Friedland wrote:
"It isn't just the typing response. The main thread is used for
updating
the UI and things scheduled with AppClock, so it is really unfriendly
to other tasks to be throwing away CPU cycles like you had an infinite
number to burn."
This makes not sense, at least not as stated...
UI updates have to happen on some thread(s) and they can happen on
threads other then the applications main thread (e.g. Cocoa itself uses
a secondary UI heartbeat thread for UI animation) however the main
thread is often the one that does most of the UI and event management
by convention.
Of course the more threads you involve in the same task the more
overhead you have with context switching, locking and lock contention
that can degrade performance by wasting cycles... so it almost sounds
like he is arguing for the very thing he is worried about...?
Anyway if the UI doesn't need to be updated, no timer have fired, or no
events have been received by the application then no CPU time is taken
by the application. In fact Cocoa applications and Carbon event based
applications use the same underlying systems and are very CPU friendly
when they have nothing to do (basically zero since they are blocked).
So I think he should clarify the concern that he is trying to express
in the above.
-Shawn
_______________________________________________
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