2016-08-30 10:41 GMT+02:00 Norbert Hartl <norb...@hartl.name>: > > Am 30.08.2016 um 09:44 schrieb Denis Kudriashov <dionisi...@gmail.com>: > > Hi > > 2016-08-30 8:52 GMT+02:00 Norbert Hartl <norb...@hartl.name>: > >> I think for the 0 case we should think about instantiating the >> SubscriptionRegistry lazily. This would also mitigate the effect that if a >> lot of announcers are created they create only a single object instead of >> two until used. Of course this depends on the probability of having a lot >> of announcers where only a few are used. >> The #announce: method looks like it has been lazy before. >> >> Announcer>>#announce: anAnnouncement >> >> | announcement | >> announcement := anAnnouncement asAnnouncement. >> registry ifNotNil: [ >> registry deliver: announcement >> ]. >> ^ announcement >> >> checks for #ifNotNil: but registry is created in #initialize. So >> #ifNotEmpty: would be right here but #deliver: checks that, too. >> > > We always hide announcer instance inside owner. So it could instantiate > announcer lazily if such optimization really needed. > > > That prevents creating an announcer until someone creates the announcer > lazily. That does not mean there is a subscription, especially if there are > announcements sent. Announcements are such a central component (we made it > that way) that every useful optimization should be considered! >
Agreed. The slightly tricky part is effectively to ensure that sending an announcement doesn't lazily create the announcer. But, overall, the code isn't that complex, so it is worth optimising for it (IMHO). The software engineering issue is that the optimisation is done in the code using the announcer object (for example, Morph) and not in the Announcer instance itself, which would make the optimisation applied everywhere. However, the benefit is that you do it only in places where you think it is necessary, not everywhere for everybody. This optimisation will have a cost for some operations (*), and so it may not be suitable everywhere. Thierry (*) I'm thinking of subscriptions removal there. Useless to optimise that for Morphs, for example (it would be very rare to see an object subscribe to a Morph, then unsubscribe). However, for the system announcer, given the number of objects subscribing / unsubscribing to it, don't try to optimise the no subscribers case! > > Norbert > >
