Hi Stef,
2016-09-01 8:13 GMT+02:00 stepharo <[email protected]>: > 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 >>>> <[email protected]> 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 >>> >>> >> >> >> > >
