About the non-use of Announcer in Bloc

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.

2016-08-30 8:52 GMT+02:00 Norbert Hartl <[hidden email]>:

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.

Hi

2016-08-30 8:52 GMT+02:00 Norbert Hartl <[hidden email]>:

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.

Hi,

From the top of my head: I would understand that systems where there are hundreds of thousands of events per second, maybe one does not want to pay the overhead of announcements...

But, How many events are produced from a morph per second? One? Two? Five? Is it really the case of morphs the one that require optimization?

2016-08-30 10:21 GMT+02:00 Guille Polito <[hidden email]>:

Hi,

From the top of my head: I would understand that systems where there are hundreds of thousands of events per second, maybe one does not want to pay the overhead of announcements...

But, How many events are produced from a morph per second? One? Two? Five? Is it really the case of morphs the one that require optimization?

I have similar feeling. But maybe Spec is nice example which could improved by such optimizations

Am 30.08.2016 um 09:44 schrieb Denis Kudriashov <[hidden email]>:

Hi

2016-08-30 8:52 GMT+02:00 Norbert Hartl <[hidden email]>:

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!

Norbert

2016-08-30 10:28 GMT+02:00 Denis Kudriashov <[hidden email]>:

2016-08-30 10:21 GMT+02:00 Guille Polito <[hidden email]>:

Hi,

From the top of my head: I would understand that systems where there are hundreds of thousands of events per second, maybe one does not want to pay the overhead of announcements...

But, How many events are produced from a morph per second? One? Two? Five? Is it really the case of morphs the one that require optimization?

I have similar feeling. But maybe Spec is nice example which could improved by such optimizations

No. Announcers are not the problem in Spec

2016-08-30 10:35 GMT+02:00 Thierry Goubier <[hidden email]>:

2016-08-30 10:28 GMT+02:00 Denis Kudriashov <[hidden email]>:

2016-08-30 10:21 GMT+02:00 Guille Polito <[hidden email]>:

Hi,

From the top of my head: I would understand that systems where there are hundreds of thousands of events per second, maybe one does not want to pay the overhead of announcements...

But, How many events are produced from a morph per second? One? Two? Five? Is it really the case of morphs the one that require optimization?

I have similar feeling. But maybe Spec is nice example which could improved by such optimizations

No. Announcers are not the problem in Spec

I just saw that every property in Spec model's is kind of ValueHolder with announcer instance inside. And it is huge number. But I think in case of Spec they are always used. So laziness will not helps here. But optimisation for single subscriber could.

On 29 Aug 2016, at 6:39 , Denis Kudriashov <[hidden email]> wrote:

And now question is why SubscriptionRegistry manages subscriptions as IdentitySet instead of OrderedCollection? 

1) Performance of remove operation is the main reason. Sure, registration has a larger constant overhead than using an OrderedCollection, but it's still a theta(1) operation.Removal however, is theta(1)'ish, while with OrderedCollection, it would be theta(n/2). So for a general implementation where the usage pattern is unknown, it gives more balanced performance considering all use cases. *

2) Lessen chance of user relying on delivery order implied by registration order.

And yes, it's possible to create much better performing announcers for specific use patterns, such as a (short-lived) announcer where there's a period of registration, followed by a period of delivery, before eventual garbage collection of the announcer rather than explicit deregistration.

Personally, I think the (original) announcer pattern, where subscription collection is copied at registration, then replaced atomically, would be a better alternative.

You'd still need a mutex for the copy->add part to keep it thread-safe, but delivery would have much less overhead (no copy needed to avoid mutex guarding against mutation)

I'd be *very* wary of adding announcers that do not have thread-safe interaction between registration and delivery, though one suited for registration limited to a single thread may be a valid scenario.

Cheers,

Henry

> On 30 Aug 2016, at 5:16 , Thierry Goubier <[hidden email]> wrote:
>
>
> I have the same concern with an Announcer optimized for certain use cases, in the fact that the announcer creator is the one choosing the 'kind of' optimisation it would target, hoping that the listeners will conform to that use case...


There simply is no silver bullet that will give unbeatable performance in all scenarios; and focusing on improving one facet of the default implementation will inevitably lead to either
- the loss of some important property (general thread-safety if removing the mutex protection, ability to unsubscribe in handler if removing the copy operation and extending the delivery mutex protection, etc.)
- greatly degenerated performance for another facet (like #remove for OC's).

That said, the current implementation is very geared towards decent, balanced subscribe/unsubscribe performance, at the expense of delivery speed.
I've said it before, and still think, that offering at least one other implementation emphasizing delivery speed over subscription/unsubscription performance, in the same way the original implementation did (and/or changing the default Announcer to switch between the two dynamically based on heuristics) *would* be a valuable addition to the general library.

Cheers,
Henry

Hi all (I was out for some days),

What i see is that Bloc EventRegistry:
1) is not thread safe (no mutex + #select:thenDo:)
2) doesn't allow handler removal from the handler list currently used in the
thenDo: loop
3) is used specifically for a one-to-many communication (1 BlElement -> X
handlers)

The (1) doesn't seem to be a problem in Bloc during UI event processing
because a new event handler, even if it is added from another thread, would
be taken into account for the next event.

I note that it is really not
recommended (at all) to update an UI element elsewhere than in the UI thread
and it is like that in all other UI frameworks i know.

The (2) is a very specific use case and i don't know if it is a real need in
Bloc because this implies that an element has 2 handlers for the same event
and one of them has to remove the other before it is executed and during the
same event processing (maybe more a conception issue than a common use
case...). In other cases, no problem for handler removal.

But maybe i miss some specific cases in (1) and in (2).

To me, Announcer is really usefull and efficient when it is used as an event
bus that can be shared between multiple objects.
For instance, it seems to be useless to use an Announcer in NewValueHolder
because it cannot be shared and it is only used internally to register
handlers and to propagate only the same event (ValueChanged) to them. What
is the gain of using a full featured Announcer in this case?

In Bloc the constraint is to propagate more than 2000 events/second without
to decrease fps, so we cannot afford to x4 the time to process events even
if Announcer is safer and better tested.