Re: Should I observe every object in my view, or just the visible ones?
Re: Should I observe every object in my view, or just the visible ones?
- Subject: Re: Should I observe every object in my view, or just the visible ones?
- From: Scott Ellsworth <email@hidden>
- Date: Tue, 17 May 2005 11:26:13 -0700
Thanks, mmalc, j o a r.
On May 16, 2005, at 12:18 PM, mmalcolm crawford wrote:
On May 16, 2005, at 11:57 AM, Scott Ellsworth wrote:
I have a view that shows roughly 500 objects out of 5000 in the
data store, but depending on resolution and window size, the user
can actually only see about 100 to 150 of them. Currently,
changes to model objects do not show up in the view, and I would
like them to.
The fundamental question is, what additional work is done by
observing something?
The fundamental answer as it relates to your situation is
*probably*, the registration process.
'Kay.
If an object isn't doing anything, there's no KVO overhead. If an
object changes, it sends KVO notifications. That represents an
"overhead", but one you'd probably incur anyway as you have to
synchronise your application.
Yep.
As it relates to a drawing application:
The main question would be, how many off-screen objects will be
changing how often? And if they're changing, will the change bring
them on-screen?
Changes will never bring an offscreen object on screen. Changes are
frequent, and about four times more likely to occur offscreen than
on. (A simulator is running, you see, and it changes objects all
over the object graph.)
Changes come from two sources: the user editing a single object in a
table view, and a simulator changing something between a tenth and a
quarter of the objects in one fell swoop.
I'd imagine that a significant overhead in the application will be
drawing?
Yep. Drawing is my big bottleneck right now.
And I'd also imagine that the view doesn't redraw objects that are
outside its bounds?
Yep.
So assuming that off-screen objects change rarely and that even
when they do there's no impact on drawing, the overhead is likely
to be negligible. Occasionally a change might bring an object on-
screen, so you'd need to know about that event anyway.
Ok - while my offscreen objects will actually be changing a fair
amount, drawRect is quite efficient about not doing anything if the
changes are offscreen. Thus, as long as the overhead of a signal is
not huge, drawing is going to stay the big cost.
The only additional overhead, then, is likely to be "unnecessary"
registration of objects. How much of an impact this represents
will depend on usage patterns. Are all the objects added to a
document in one go?
Yes - it is very difficult to add an object after the fact. I am
working on that now, but it is lower priority than getting the
simulation part working.
How intensive a process is that? Does the user have to wait now
anyway? Do they add objects one at a time? If so, then the
additional overhead of registration will be lost in the noise.
Even once it works, object adds will be infrequent, and a bit of a
delay will not be noticeable.
Finally, if you don't observe everything, what will be the overhead
of whatever mechanism you choose to keep track of what it is you
need to observe and what you don't?
This is what worried me in the first place - every smart mechanism
sounded hard.
The one question I have now is where I would see excessive
notifications showing up in Shark. observeValueForKeyPath?
Scott
_______________________________________________
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