Re: delayed read-only bindings (suggestions/hints) ?
Re: delayed read-only bindings (suggestions/hints) ?
- Subject: Re: delayed read-only bindings (suggestions/hints) ?
- From: Nicko van Someren <email@hidden>
- Date: Wed, 21 Apr 2004 11:59:51 +0100
On 21 Apr 2004, at 10:53, Nicolas Berloquin wrote:
My problem is that currently, as data arrives, I update, for example
some
model values that sum received data. This value is bound to a table
column.
When data arrives very fast, the window gets updated *very* often,
resulting in my
app's cpu usage between 40-70% and WindowServer around 70% (I have a
few fields
updated that way...)
...
I thought about two different solutions:
- One, which I already implement for some values, is to have an
NSTimer fire every second
that updates a second (mirror) value with whatever changes apply. This
mirror value is the
one that is bound to the tableColumn. This works fine, but I don't
know how expensive are
NSTimers (what if I have a dozen running ? a hundred ?)
I don't think that timers are very expensive, especially if they are
only firing once a second.
- Second solution would be to "hack" the NSArrayController. (Please
remember that this is
for READ-ONLY values, displayed in a window). I haven't tried this
yet, but I thought about
things like unbinding/binding the arraycontroller every n seconds. How
expensive is the binding
/unbinding in this case ?
Binding is done using a technique called "isa-swizzling". Basically
when you bind an observer the system switches the 'isa' pointer to the
class dispatch table to change it for a version that catches all the
value setting operations and allows them to generate a notification. I
suspect that this is fairly cheap in comparison to the overall cost of
using binding at all. Some implementation details can be found at:
http://developer.apple.com/documentation/Cocoa/Conceptual/
KeyValueObserving/index.html?
http://developer.apple.com/documentation/
Cocoa/Conceptual/KeyValueObserving/Concepts/KVOBasics.html
Or caching the observed value changes, then batch-updating all the
updates every n seconds
(ugly/complicated eh ?)
I think that this is actually a fairly good way to do it. You have a
single timer that goes off however often you want to do update, once a
second say, and you set up an NSMutableSet of things that need to get
refreshed. You bind to the data source an observer that simply adds
the object that changed to the set (which has no effect if it's already
in there) and then when your timer goes off you look at the set,
refresh/redisplay everything that's in it and then call
removeAllObjects and go around again.
Any plans for an NSTimedDelayArrayController ? ^_^
Sounds like a plan. Send me a copy when you've written it!
Cheers,
Nicko
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.