About the non-use of Announcer in Bloc
Locked
123
123
About the non-use of Announcer in Bloc
 
|
Hi all,
Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of Announcer in Bloc. I made some test cases in Bloc-Tests to compare performances between Announcer and BlEventRegistry. The result is that Announcer is at least 5x slower in all tested cases. Bloc has only specific needs about event dispatching, the first one is the efficiency during event propagation. It may be interesting to investigate why Announcer is slower and also what are the uncovered cases in BlEventRegistry. So, i'm interested in continuing our discussion about that. Regards, Glenn.
Glenn Cavarlé
|
Re: About the non-use of Announcer in Bloc
|
Probably from the use of critical (mutex), the way #subscriptionsHandling: is done, and that Announcer is built for X number of announcers and Y number of subscribers, which means that each announcement the announcer has to filter and find the correct subscribers.
---- | ann a | ann := Announcer new. ann when: Announcement do: [ :e ]. a := Announcement new. [[ ann announce: a ] bench ] timeProfile ----- Other drawbacks to consider when using announcements: Memory overhead from the Announcer object and each subscription. Memory ownership, the announcement subscriptions will strongly reference the announcement target unless the announcement is weakly, which can lead to memory leakage especially if strong and weak subscriptions are mixed in certain situations (see the mailing list from around the release of Pharo 6). This also leads to code where the announcer is the one who owns the target (multiple times if there are different announcements), which makes understanding who references what etc.. much harder to understand. In many places the control/message flow, and the relationship between the different parts of a bigger object tends to become much more difficult to understand (For example Rubric). Announcer usage shines when there is a need for a common place that X objects can communicate Y messages to Z recipients without needing to know who sends what, or who wants to receive what (For example System Announcements). Communication when only one Object "A" announces to another Object(s) "B", is better implemented as A referencing B, then B implements the necessary methods needed for this communication. Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:[hidden email]] On Behalf Of Glenn Cavarlé Sent: Sunday, August 28, 2016 9:11 PM To: [hidden email] Subject: [Pharo-dev] About the non-use of Announcer in Bloc Hi all, Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of Announcer in Bloc. I made some test cases in Bloc-Tests to compare performances between Announcer and BlEventRegistry. The result is that Announcer is at least 5x slower in all tested cases. Bloc has only specific needs about event dispatching, the first one is the efficiency during event propagation. It may be interesting to investigate why Announcer is slower and also what are the uncovered cases in BlEventRegistry. So, i'm interested in continuing our discussion about that. Regards, Glenn. ----- Glenn Cavarlé -- View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. |
Re: About the non-use of Announcer in Bloc
|
|
In reply to this post by Glenn Cavarlé
Hi Glenn,
Thanks a lot for this experiment. Could you send us the code snippet so people can play with it? The question is if perhaps we can identify a slimmer announcement support so that people can choose depending on requirements (e.g. parallelism or not). Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow" > On 28 Aug 2016, at 21:11, Glenn Cavarlé <[hidden email]> wrote: > > Hi all, > Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of > Announcer in Bloc. > I made some test cases in Bloc-Tests to compare performances between > Announcer and BlEventRegistry. > The result is that Announcer is at least 5x slower in all tested cases. > Bloc has only specific needs about event dispatching, the first one is the > efficiency during event propagation. > It may be interesting to investigate why Announcer is slower and also what > are the uncovered cases in BlEventRegistry. > So, i'm interested in continuing our discussion about that. > > Regards, > Glenn. > > > > ----- > Glenn Cavarlé > -- > View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
Re: About the non-use of Announcer in Bloc
|
|
Hi 2016-08-29 8:25 GMT+02:00 Tudor Girba <[hidden email]>:
Or some links where to download image with Bloc-Tests |
Re: About the non-use of Announcer in Bloc
|
|
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é
|
Re: About the non-use of Announcer in Bloc
|
|
Hi,
And the script is? :) Doru > On Aug 29, 2016, at 4:31 PM, Glenn Cavarlé <[hidden email]> wrote: > > 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-tp4913008p4913079.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different." |
Re: About the non-use of Announcer in Bloc
|
|
In reply to this post by Glenn Cavarlé
And could you write current repository? 2016-08-29 16:31 GMT+02:00 Glenn Cavarlé <[hidden email]>: You can load Bloc and show the tests using this script: |
Re: About the non-use of Announcer in Bloc
|
|
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 <[hidden email]> wrote: > > And could you write current repository? > > 2016-08-29 16:31 GMT+02:00 Glenn Cavarlé <[hidden email]>: > 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-tp4913008p4913079.html > 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." |
Re: About the non-use of Announcer in Bloc
|
|
This post was updated on .
In reply to this post by Tudor Girba-2
Ha... raw 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é
|
Re: About the non-use of Announcer in Bloc
|
|
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é <[hidden email]>: Ha... tag doesn't work... |
Re: About the non-use of Announcer in Bloc
|
|
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 <[hidden email]>:
|
Re: About the non-use of Announcer in Bloc
|
|
And now question is why SubscriptionRegistry manages subscriptions as IdentitySet instead of OrderedCollection? 2016-08-29 18:36 GMT+02:00 Denis Kudriashov <[hidden email]>:
|
|
|
In reply to this post by Glenn Cavarlé
Thanks Glenn!!!!!!!!!!!!!!!!!!!!!!!
> Hi all, > Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of > Announcer in Bloc. > I made some test cases in Bloc-Tests to compare performances between > Announcer and BlEventRegistry. > The result is that Announcer is at least 5x slower in all tested cases. > Bloc has only specific needs about event dispatching, the first one is the > efficiency during event propagation. > It may be interesting to investigate why Announcer is slower and also what > are the uncovered cases in BlEventRegistry. > So, i'm interested in continuing our discussion about that. > > Regards, > Glenn. > > > > ----- > Glenn Cavarlé > -- > View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > |
|
|
In reply to this post by Henrik Nergaard
Hi henrik
thanks for your analysis. I always wanted to deeply understand the difference between announcements and a simple registry mechanism. Now I'm too tired to think (yes I need to sleep a 9h25 :) but I will reread this mail when my brain is back . stef Le 29/8/16 à 00:54, Henrik Nergaard a écrit : > Probably from the use of critical (mutex), the way #subscriptionsHandling: is done, and that Announcer is built for X number of announcers and Y number of subscribers, which means that each announcement the announcer has to filter and find the correct subscribers. > ---- > > | ann a | > > ann := Announcer new. > > ann when: Announcement do: [ :e ]. > a := Announcement new. > [[ ann announce: a ] bench ] timeProfile > > ----- > > Other drawbacks to consider when using announcements: > Memory overhead from the Announcer object and each subscription. > Memory ownership, the announcement subscriptions will strongly reference the announcement target unless the announcement is weakly, which can lead to memory leakage especially if strong and weak subscriptions are mixed in certain situations (see the mailing list from around the release of Pharo 6). This also leads to code where the announcer is the one who owns the target (multiple times if there are different announcements), which makes understanding who references what etc.. much harder to understand. > In many places the control/message flow, and the relationship between the different parts of a bigger object tends to become much more difficult to understand (For example Rubric). > > Announcer usage shines when there is a need for a common place that X objects can communicate Y messages to Z recipients without needing to know who sends what, or who wants to receive what (For example System Announcements). > > Communication when only one Object "A" announces to another Object(s) "B", is better implemented as A referencing B, then B implements the necessary methods needed for this communication. > > Best regards, > Henrik > > > > -----Original Message----- > From: Pharo-dev [mailto:[hidden email]] On Behalf Of Glenn Cavarlé > Sent: Sunday, August 28, 2016 9:11 PM > To: [hidden email] > Subject: [Pharo-dev] About the non-use of Announcer in Bloc > > Hi all, > Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of Announcer in Bloc. > I made some test cases in Bloc-Tests to compare performances between Announcer and BlEventRegistry. > The result is that Announcer is at least 5x slower in all tested cases. > Bloc has only specific needs about event dispatching, the first one is the efficiency during event propagation. > It may be interesting to investigate why Announcer is slower and also what are the uncovered cases in BlEventRegistry. > So, i'm interested in continuing our discussion about that. > > Regards, > Glenn. > > > > ----- > Glenn Cavarlé > -- > View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
Re: About the non-use of Announcer in Bloc
|
|
In reply to this post by Denis Kudriashov
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. 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 <[hidden email]> 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 <[hidden email]>: > 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é <[hidden email]>: > 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-tp4913008p4913088.html > 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 29 Aug 2016, at 21:37, Tudor Girba <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>: >> 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é <[hidden email]>: >> 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-tp4913008p4913088.html >> 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." > > > > > > |
Re: About the non-use of Announcer in Bloc
|
|
2016-08-29 21:50 GMT+02:00 Yuriy Tymchuk <[hidden email]>: > 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 looks quite safe to not check anything because subscription items are instances of AnnouncementSubscription which are created internally inside Announcer during subscription |
Re: About the non-use of Announcer in Bloc
|
|
> On Aug 29, 2016, at 10:37 PM, Denis Kudriashov <[hidden email]> wrote: > > > 2016-08-29 21:50 GMT+02:00 Yuriy Tymchuk <[hidden email]>: > > 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." |
Re: About the non-use of Announcer in Bloc
|
|
In reply to this post by Denis Kudriashov
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. Stephan |
|
|
In reply to this post by Tudor Girba-2
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 <[hidden email]> 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 <[hidden email]>: >> 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é <[hidden email]>: >> 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-tp4913008p4913088.html >> 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." > > > > > > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |