Re: Notification redundancy
Re: Notification redundancy
- Subject: Re: Notification redundancy
- From: Marco Scheurer <email@hidden>
- Date: Thu, 29 Jan 2004 17:47:27 +0100
On Jan 28, 2004, at 4:09 PM, Erez Anzel wrote:
I have enjoyed using the notification system built into Cocoa. But the
standard approach may not be the wisest in my situation, where I may
have tens of thousands of objects sending notifications, and multiple
observers.
If the user changes 50,000 objects in one action, and I use the
"standard" Cocoa approach, then 50,000 notifications are sent to my
registered observer(s), each with its own dictionary attached. (Each
notification comes from the object's primitive "set" method.) Three
views onto the same data means that each notification is observed and
acted upon three times, for a total of 150,000 observations and
reactions. Probably pumps up RAM usage as well, since I can't create
and release my own pool for these notifications; they have to persist
past the time that my action method completes its task.
In a case like this, it's more efficient for the action method to post
the notification, instead of each object. I could make a decision at
runtime as to whether the action posts the notification, or each
object, depending upon how many objects are involved. But this starts
to get messy; I have many different actions, many object types, and
many "set" methods for each.
Any wisdom on this issue?
If they are really redundant, then you can coalesce them. One way of
doing this is to post the notification using a
performSelector:withObject:afterDelay: /
cancelPreviousPerformRequestsWithTarget:selector:object: pattern.
If there are just many of them, but they rae all different it is likely
that one action that changes many things in one go implies a higher
level method that could send just one notification. You don't want to
do it in the action (presumably in the controller) which makes sense,
but maybe you need to add something to the model.
Marco Scheurer
Sen:te, Lausanne, Switzerland
http://www.sente.ch
_______________________________________________
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.