2016-08-30 17:36 GMT+02:00 Henrik Johansen <[email protected]>:
> > > 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. > Intuitively, I would say that delivery speed would be more important. But I wonder what would be a way to ensure we optimise for the correct usual use. Either way, I agree with you about the interest of another implementation targetting faster delivery. Regards, Thierry > Cheers, > Henry > >
