Pharo-dev

By thread

pharo-dev@lists.pharo.org

September 2016

671 messages

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by stepharo

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(a)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 >> > > >

Sept. 1, 2016

Jump to page: