2016-08-30 17:36 GMT+02:00 Henrik Johansen <henrik.s.johansen@veloxit.no>:

> On 30 Aug 2016, at 5:16 , Thierry Goubier <thierry.goubier@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.

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