You can load Bloc and show the tests using this script: ----- Glenn Cavarlé -- View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p49130... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Ha... tag doesn't work... You can load Bloc and show the tests using this script: Gofer it smalltalkhubUser: 'Pharo' project: 'Bloc'; configuration; loadDevelopment. Gofer it smalltalkhubUser: 'Pharo' project: 'Bloc'; package: 'Bloc-Tests'; load. BlAnnouncerVsBlEventRegistryTest browse ----- Glenn Cavarlé -- View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p49130... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

And expenses to deliver announcement caused also by protection and usage of IdentitySet. Also in announcements we first collect all subscriptions with interest to separate collection and only after we iterate and process given announcement. But in Bloc you use #select:thenDo: method instead. It is unsafe because event handlers can be modified during delivering (by producing new subscriptions or by unsubscribing inside handlers). So if you want to address it (and I sure you do) it will lead to same code and performance of announcements. 2016-08-29 18:05 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

Thank's. I try tests for subscribing and what I found is:

Main problem that subscriptions inside SubscriptionRegistry are managed as IdentitySet which of cause much slower for addition then OrderedCollection. We probably could use OrderedCollection here because items are always created on fly and identitySet has no sense.

Another problem is access protection by mutex (semaphore) which make it 3 times slower.

So with OrderedCollection and disabled mutex performance for subscribing is same.

I pretty sure that protection is required for Block handlers too.

2016-08-29 17:18 GMT+02:00 Glenn Cavarlé <glenn.cavarle@gmail.com>:

...

Ha... tag doesn't work...

You can load Bloc and show the tests using this script: Gofer it smalltalkhubUser: 'Pharo' project: 'Bloc'; configuration; loadDevelopment. Gofer it smalltalkhubUser: 'Pharo' project: 'Bloc'; package: 'Bloc-Tests'; load. BlAnnouncerVsBlEventRegistryTest browse

----- Glenn Cavarlé -- View this message in context: http://forum.world.st/About-th e-non-use-of-Announcer-in-Bloc-tp4913008p4913088.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

On 29 Aug 2016, at 6:39 , Denis Kudriashov <dionisiydk@gmail.com> 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 <thierry.goubier@gmail.com> 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

Numbers for the discussion: No activity, empty desktop: announcements 608/minute subscribe add/remove 9/minute Activity, AltBrowser: announcements 1109/minute subscribe add/remove 207/minute Activity, Nautilus: announcements 2488/minute subscribe add/remove 716/minute Empirically the same processus in both environments: open two system browser, in one, find the Announcer class, browse through a few of the methods, select basicSubscribe: and ask for senders. Tracing done with Metalinks during one minute. Not exactly what I would have expected, especially the ratio subscribe add/remove and announcements. Thierry Le 30/08/2016 à 17:36, Henrik Johansen a écrit :

...

On 30 Aug 2016, at 5:16 , Thierry Goubier <thierry.goubier@gmail.com> 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

2016-08-31 10:10 GMT+02:00 Glenn Cavarlé <glenn.cavarle@gmail.com>:

Hi all (I was out for some days),

Hi Glenn

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.

Problem that concurrent modification of OrderedCollection could just fail. You will got debugger.

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.

Does it means that I should not subscribe on UI events from different (not UI) processes? How to do this if it is needed? Should I always put subscription code into #defer: message (analogue)? In that case what to do if I need to be sure that I really subscribe on event and only after this continue my business logic process?

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.

Very simple example: I want one shot handler for MouseMove to highlight element once to see that my mouse was moved around. So my handler will highlight target element and unsubscribe it immediately. Problem that if you do it on OrderedCollection during iteration you could skip one of the handlers. And probably some failures are also possible (debugger again). Of course you could say users do not do all of this. But what the alternative? And if people will do this by "incident" it will be very difficult to discover reasons.

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?

But in practice we never share any announcer instance. We always hide it inside owner object. ValueHolder is not specific example. Also ValueHolder is kind of active model for UI application which could be shared between different views. And when it will be modified in one view another view will be updated automatically.

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.

I wondering what the source of this constraint? Does Morphic follows it? I guess not, but all Pharo works quite well with it.

Le 31/8/16 à 11:23, Denis Kudriashov a écrit :

2016-08-31 10:10 GMT+02:00 Glenn Cavarlé <glenn.cavarle@gmail.com <mailto:glenn.cavarle@gmail.com>>:

Hi all (I was out for some days),

Hi Glenn

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.

Problem that concurrent modification of OrderedCollection could just fail. You will got debugger.

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.

Does it means that I should not subscribe on UI events from different (not UI) processes? How to do this if it is needed? Should I always put subscription code into #defer: message (analogue)? In that case what to do if I need to be sure that I really subscribe on event and only after this continue my business logic process?

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.

Very simple example: I want one shot handler for MouseMove to highlight element once to see that my mouse was moved around. So my handler will highlight target element and unsubscribe it immediately. Problem that if you do it on OrderedCollection during iteration you could skip one of the handlers. And probably some failures are also possible (debugger again).

Of course you could say users do not do all of this. But what the alternative? And if people will do this by "incident" it will be very difficult to discover reasons.

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?

But in practice we never share any announcer instance.

Really? You lost me on that sentence. SystemAnnouncer current is shared by all the tools no?

We always hide it inside owner object. ValueHolder is not specific example. Also ValueHolder is kind of active model for UI application which could be shared between different views. And when it will be modified in one view another view will be updated automatically.

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.

I wondering what the source of this constraint? Does Morphic follows it? I guess not, but all Pharo works quite well with it.

2016-09-01 9:57 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

Really? You lost me on that sentence. SystemAnnouncer current is shared by

...

all the tools no?

Yes, you are right. I forgot this big monster :). Now I look at senders of #announcer and there are many places with chain like "aSomebody announcer when:send:..." or also "aSomebody somebodyElse announcer when:send:...". So forgot my words :)

But these places are definitely smell.

2016-08-31 18:01 GMT+02:00 Henrik Johansen <henrik.s.johansen@veloxit.no>:

On 31 Aug 2016, at 10:10 , Glenn Cavarlé <glenn.cavarle@gmail.com> wrote:

In Bloc the constraint is to propagate more than 2000 events/second without to decrease fps

That's only a small part of the picture though, how many listeners are there per each event? And how large do you think the overhead specific to delivery guards is compared to the constraint propagation handlers?

On my machine (an old 2011 MBP), the following gives throughput on the order of 300k-600k deliveries per second (very variable, due to the amount of garbage generated from copying subs, I presume)

So close to 3 times the performance of entry-level celeron for laptops today (if I take the lowest of the 15" MBP of early 2011).

#(1 10 100 1000) collect: [ :listeners |

a := Announcer new. b := Object new. "Single message send in handler" listeners timesRepeat: [a when: Announcement do: [ :a | a yourself ] for: b.]. "announcement creation overhead not included" ann := Announcement new. [a announce: ann] bench].

Cheers, Henry

And with a registry tuned for delivery, yet maintaining the guards (attached)/exception/error handling properties, 900k -> 2.5M

#(1 10 100 1000) collect: [ :listeners |

a := Announcer new. b := Object new. a instVarNamed: 'registry' put: DeliveringSubscriptionRegistry new. "Single message send in handler" listeners timesRepeat: [a when: Announcement do: [ :a | a yourself ] for: b.]. "announcement creation overhead not included" ann := Announcement new. [a announce: ann] bench.].

Thanks for the numbers. We need those to optimise what really matters :) Thierry

Hi thierry I think that if we would have a tool to show us the activity I'm quite sure that we would find bugs or mistaken behavior. could you send the scripts you did? Stef Le 30/8/16 à 22:36, Thierry Goubier a écrit :

Numbers for the discussion:

No activity, empty desktop: announcements 608/minute subscribe add/remove 9/minute

Activity, AltBrowser: announcements 1109/minute subscribe add/remove 207/minute

Activity, Nautilus: announcements 2488/minute subscribe add/remove 716/minute

Empirically the same processus in both environments: open two system browser, in one, find the Announcer class, browse through a few of the methods, select basicSubscribe: and ask for senders.

Tracing done with Metalinks during one minute.

Not exactly what I would have expected, especially the ratio subscribe add/remove and announcements.

Thierry

Le 30/08/2016 à 17:36, Henrik Johansen a écrit :

...

...

On 30 Aug 2016, at 5:16 , Thierry Goubier <thierry.goubier@gmail.com> 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 Stef, here is the script I use: | c1 c2 c3 n1 n2 n3 l1 l2 l3 | c1 := c2 := c3 := 0. n1 := (Announcer>>#announce:) ast. n2 := #(subscribe:do: subscribe:send:to: basicSubscribe:) collect: [ :e | (Announcer>>e) ast ]. n3 := #(unsubscribe: removeSubscription:) collect: [ :e | (Announcer>>e) ast ]. l1 := MetaLink new metaObject: [ c1 := c1 + 1 ]; selector: #value. l2 := MetaLink new metaObject: [ c2 := c2 + 1 ]; selector: #value. l3 := MetaLink new metaObject: [ c3 := c3 + 1 ]; selector: #value. [ n1 link: l1. n2 do: [ :e | e link: l2 ]. n3 do: [ :e | e link: l3 ]. (Duration minutes: 1) wait. n1 removeLink: l1. n2 do: [ :e | e removeLink: l2 ]. n3 do: [ :e | e removeLink: l3 ]. { 'announce' -> c1. 'subscribe' -> c2. 'unsubscribe' -> c3 } inspect ] forkAt: Processor userBackgroundPriority [image: Images intégrées 1] 2016-09-01 9:28 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

Hi Stef,

2016-09-01 8:13 GMT+02:00 stepharo <stepharo@free.fr>:

...

Hi thierry

I think that if we would have a tool to show us the activity I'm quite sure that we would find bugs

or mistaken behavior.

Yes. I did some checks on Morphic and AltBrowser after getting the numbers, to see if I wasn't doing something wrong with my code.

could you send the scripts you did?

...

Later today. I don't have access now to the laptop where I did it.

Thierry

...

Stef

Le 30/8/16 à 22:36, Thierry Goubier a écrit :

Numbers for the discussion:

...

No activity, empty desktop: announcements 608/minute subscribe add/remove 9/minute

Activity, AltBrowser: announcements 1109/minute subscribe add/remove 207/minute

Activity, Nautilus: announcements 2488/minute subscribe add/remove 716/minute

Empirically the same processus in both environments: open two system browser, in one, find the Announcer class, browse through a few of the methods, select basicSubscribe: and ask for senders.

Tracing done with Metalinks during one minute.

Not exactly what I would have expected, especially the ratio subscribe add/remove and announcements.

Thierry

Le 30/08/2016 à 17:36, Henrik Johansen a écrit :

...

On 30 Aug 2016, at 5:16 , Thierry Goubier

...

<thierry.goubier@gmail.com> 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

2016-09-01 10:29 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

Hi Thierry.

2016-09-01 10:21 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

...

(Duration minutes: 1) wait.

Just to mention our nice language: it could be written as:

1 minutes wait

Thanks. Didn't find that one when searching through the code. Recovering the userBackgroundPriority message by code browsing and search wasn't too obvious either.

Thierry

this is really cool :) Le 1/9/16 à 10:21, Thierry Goubier a écrit :

Hi Stef,

here is the script I use:

| c1 c2 c3 n1 n2 n3 l1 l2 l3 | c1 := c2 := c3 := 0. n1 := (Announcer>>#announce:) ast. n2 := #(subscribe:do: subscribe:send:to: basicSubscribe:) collect: [ :e | (Announcer>>e) ast ]. n3 := #(unsubscribe: removeSubscription:) collect: [ :e | (Announcer>>e) ast ]. l1 := MetaLink new metaObject: [ c1 := c1 + 1 ]; selector: #value. l2 := MetaLink new metaObject: [ c2 := c2 + 1 ]; selector: #value. l3 := MetaLink new metaObject: [ c3 := c3 + 1 ]; selector: #value. [ n1 link: l1. n2 do: [ :e | e link: l2 ]. n3 do: [ :e | e link: l3 ]. (Duration minutes: 1) wait. n1 removeLink: l1. n2 do: [ :e | e removeLink: l2 ]. n3 do: [ :e | e removeLink: l3 ]. { 'announce' -> c1. 'subscribe' -> c2. 'unsubscribe' -> c3 } inspect ] forkAt: Processor userBackgroundPriority

Images intégrées 1

2016-09-01 9:28 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:

Hi Stef,

2016-09-01 8:13 GMT+02:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:

Hi thierry

I think that if we would have a tool to show us the activity I'm quite sure that we would find bugs

or mistaken behavior.

Yes. I did some checks on Morphic and AltBrowser after getting the numbers, to see if I wasn't doing something wrong with my code.

could you send the scripts you did?

Later today. I don't have access now to the laptop where I did it.

Thierry

Stef

Le 30/8/16 à 22:36, Thierry Goubier a écrit :

Numbers for the discussion:

No activity, empty desktop: announcements 608/minute subscribe add/remove 9/minute

Activity, AltBrowser: announcements 1109/minute subscribe add/remove 207/minute

Activity, Nautilus: announcements 2488/minute subscribe add/remove 716/minute

Empirically the same processus in both environments: open two system browser, in one, find the Announcer class, browse through a few of the methods, select basicSubscribe: and ask for senders.

Tracing done with Metalinks during one minute.

Not exactly what I would have expected, especially the ratio subscribe add/remove and announcements.

Thierry

Le 30/08/2016 à 17:36, Henrik Johansen a écrit :

On 30 Aug 2016, at 5:16 , Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> 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

On 29 Aug 2016, at 21:37, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi Denis,

Thanks a lot for this analysis!

In summary, the Bloc events are faster because: 1. they store the subscriptions in OrderedCollection instead of IdentitySet. This is likely something we can improve in Announcements. 2. they are unsafe.

For 1., the only reason I can think of is to prevent the user to register twice the same object by mistake. I think this is an optimization that should be the responsibility of the user.

Alternatively we may use OrderedCollection and just check if it includes the subscription before adding. I think that more events are fired than clients are subscribed per a period of time Uko

For 2. the question is if Bloc really does not need the mutex.

Cheers, Doru

...

On Aug 29, 2016, at 6:36 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

And expenses to deliver announcement caused also by protection and usage of IdentitySet. Also in announcements we first collect all subscriptions with interest to separate collection and only after we iterate and process given announcement.

But in Bloc you use #select:thenDo: method instead. It is unsafe because event handlers can be modified during delivering (by producing new subscriptions or by unsubscribing inside handlers).

So if you want to address it (and I sure you do) it will lead to same code and performance of announcements.

2016-08-29 18:05 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>: Thank's. I try tests for subscribing and what I found is:

Main problem that subscriptions inside SubscriptionRegistry are managed as IdentitySet which of cause much slower for addition then OrderedCollection. We probably could use OrderedCollection here because items are always created on fly and identitySet has no sense.

Another problem is access protection by mutex (semaphore) which make it 3 times slower.

So with OrderedCollection and disabled mutex performance for subscribing is same.

I pretty sure that protection is required for Block handlers too.

2016-08-29 17:18 GMT+02:00 Glenn Cavarlé <glenn.cavarle@gmail.com>: Ha... tag doesn't work...

You can load Bloc and show the tests using this script: Gofer it smalltalkhubUser: 'Pharo' project: 'Bloc'; configuration; loadDevelopment. Gofer it smalltalkhubUser: 'Pharo' project: 'Bloc'; package: 'Bloc-Tests'; load. BlAnnouncerVsBlEventRegistryTest browse

----- Glenn Cavarlé -- View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p49130... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

-- www.tudorgirba.com www.feenk.com

"Every successful trip needs a suitable vehicle."

On Aug 29, 2016, at 10:37 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2016-08-29 21:50 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com>:

...

For 1., the only reason I can think of is to prevent the user to register twice the same object by mistake. I think this is an optimization that should be the responsibility of the user.

Alternatively we may use OrderedCollection and just check if it includes the subscription before adding. I think that more events are fired than clients are subscribed per a period of time

It looks quite safe to not check anything because subscription items are instances of AnnouncementSubscription which are created internally inside Announcer during subscription

+1 Doru -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

Am 30.08.2016 um 06:38 schrieb Stephan Eggermont <stephan@stack.nl>:

On 29/08/16 22:37, Denis Kudriashov wrote:

...

It looks quite safe to not check anything because subscription items are instances of AnnouncementSubscription which are created internally inside Announcer during subscription

We should probably do something special for 0 and 1 subscriptions.

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. For the 1 case we could store a single subscription in the registry field. Both subscription and registry have the #deliver: method so this would work out of the box. We could just dispatch the method. So without having measured it myself it could be good if - registry is nil if no subscribers are present. With nil checks the Announcer code could go fast - registry is a subscription in case of 1 subscriber. No need for #subscriptionsHandling: because check is directly on the subscription for #handlesAnnouncement: This should save some cycles and the creation of intermediate collections. With not using the SubscriptionRegistry there is also no #critical: section saving the creation of one. - registry is SubscriptionRegistry in case of >1 subscribers my two cents, Norbert

2016-08-30 9:44 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

2016-08-30 8:52 GMT+02:00 Norbert Hartl <norbert@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.

Interesting is slots allow to implement such pattern? I imagine AnnouncerSlot which will generate "read code" specifically depending on following message send.

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? -------- Original Message --------

2016-08-30 9:44 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>>:

Hi

2016-08-30 8:52 GMT+02:00 Norbert Hartl <norbert@hartl.name <mailto:norbert@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.

I remember making sure this was the case for Morph instances. If no subscriber, no announcer and make sure announcing something doesn't create the announcer lazily.

Thierry

2016-08-30 10:28 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

2016-08-30 10:21 GMT+02:00 Guille Polito <guillermopolito@gmail.com>:

...

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 Thierry

2016-08-30 10:35 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

2016-08-30 10:28 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

...

2016-08-30 10:21 GMT+02:00 Guille Polito <guillermopolito@gmail.com>:

...

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.

Am 30.08.2016 um 09:44 schrieb Denis Kudriashov <dionisiydk@gmail.com>:

Hi

2016-08-30 8:52 GMT+02:00 Norbert Hartl <norbert@hartl.name <mailto:norbert@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! Norbert

Le 29/8/16 à 21:37, Tudor Girba a écrit :

Hi Denis,

Thanks a lot for this analysis!

In summary, the Bloc events are faster because: 1. they store the subscriptions in OrderedCollection instead of IdentitySet. This is likely something we can improve in Announcements. 2. they are unsafe.

For 1., the only reason I can think of is to prevent the user to register twice the same object by mistake. I think this is an optimization that should be the responsibility of the user. It depends of the contract. Since we want to have a solid architecture then it should not be the responsibility of the client to me.

For 2. the question is if Bloc really does not need the mutex.

Cheers, Doru

...

On Aug 29, 2016, at 6:36 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

And expenses to deliver announcement caused also by protection and usage of IdentitySet. Also in announcements we first collect all subscriptions with interest to separate collection and only after we iterate and process given announcement.

But in Bloc you use #select:thenDo: method instead. It is unsafe because event handlers can be modified during delivering (by producing new subscriptions or by unsubscribing inside handlers).

So if you want to address it (and I sure you do) it will lead to same code and performance of announcements.

2016-08-29 18:05 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>: Thank's. I try tests for subscribing and what I found is:

Main problem that subscriptions inside SubscriptionRegistry are managed as IdentitySet which of cause much slower for addition then OrderedCollection. We probably could use OrderedCollection here because items are always created on fly and identitySet has no sense.

Another problem is access protection by mutex (semaphore) which make it 3 times slower.

So with OrderedCollection and disabled mutex performance for subscribing is same.

I pretty sure that protection is required for Block handlers too.

2016-08-29 17:18 GMT+02:00 Glenn Cavarlé <glenn.cavarle@gmail.com>: Ha... tag doesn't work...

You can load Bloc and show the tests using this script: Gofer it smalltalkhubUser: 'Pharo' project: 'Bloc'; configuration; loadDevelopment. Gofer it smalltalkhubUser: 'Pharo' project: 'Bloc'; package: 'Bloc-Tests'; load. BlAnnouncerVsBlEventRegistryTest browse

----- Glenn Cavarlé -- View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p49130... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

-- www.tudorgirba.com www.feenk.com

"Every successful trip needs a suitable vehicle."

Hi, You can find the current Bloc image here: https://ci.inria.fr/moose/job/bloc/lastSuccessfulBuild/artifact/bloc.zip Cheers, Doru

On Aug 29, 2016, at 5:10 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

And could you write current repository?

2016-08-29 16:31 GMT+02:00 Glenn Cavarlé <glenn.cavarle@gmail.com>: You can load Bloc and show the tests using this script:

----- Glenn Cavarlé -- View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p49130... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

-- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."