Re: Blocking loops
Re: Blocking loops
- Subject: Re: Blocking loops
- From: "Michael Ash" <email@hidden>
- Date: Tue, 20 Jun 2006 18:58:55 -0400
On 6/19/06, Bill Bumgarner <email@hidden> wrote:
On Jun 17, 2006, at 1:53 PM, Agent M wrote:
> At some level there will need to be some throttling- I would like
> the user to be able to use the UI while megabytes of database query
> results are streaming in and are being displayed live in a table
> view. Right now, I manually update the table view and surrounding
> info but I have to call -display or the UI never gets serviced and
> I get the beachball after a while.
Very likely -- I'm fully aware of the hostilities of networked
environments as per Mike's descriptions. Heed his words well...
This sounds like a rather demanding application in terms of network -
> display load. Even with the processing in a secondary thread, the
drawing is typically still going to be done in the MEL and you are
still going to have problems unless you are really, really careful.
A relatively simple way to fix this is to just throttle display
updates to something reasonable. As display updates in Cocoa are
frequently rather expensive, reducing their frequency can help
responsiveness a lot.
In this case, don't update the table every time data comes in.
Instead, have a "last updated" time that you track, and a minimum time
interval between updated. When new data comes in, check your last
updated; if it's old enough, update. If it's too recent, don't update,
and instead either set a timer for the expiration of your minimum
interval, or do nothing if the timer already exists.
If your minimum time interval is reasonable but small, like 1/5th or
1/10th of a second, your GUI will still updated quickly but you
shouldn't ever freeze.
_______________________________________________
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