> On 30 Aug 2016, at 5:16 , Thierry Goubier <thierry.goub...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
