Pavel Chlupacek

@vladimir-popov I am not surprised, the current implementation of topic will perfrom poorly under your load. This is sort of worst case for the current implementation. However I am quite...

Also @SystemFw, @vladimir-popov perhaps if we just change the internals of how pubsub works, perhaps we get a better performance w/o changing anything in state logic. Essentially we could try...

@SystemFw I think the issue, this demonstrates here is that you have so many concurrent attempts to CAS the State, so the overhead of this is killing the whole thing....

@SystemFw, @vladimir-popov, I have diven a bit into it, and wrote a simple bechmark, that was run with 8 threads, 500 messages in topic and 1 to 128 subscribers. Code...

@SystemFw I am not surprised that old implementation performs much better. I would say the only limit is the RAM, and obvioulsy more subscribers -> more time to publish one...

Ok, so I have changed the PubSub to use Lock + Var and this is the result : ``` [info] Benchmark Mode Cnt Score Error Units [info] TopicBenchmark.topicBroadcast_1 avgt 3...

@SystemFw this is still lock free. It uses semaphore. So it is semantically locking. I am not sure that old topic had lower contention per se. It just distributed tasks...

@SystemFw yes, and I think there is a solution with this. Event with Ref implementation. I'll update you. Essentially we use PubSub to implement topic in old way :-)

@SystemFw I think current pubsub signatures doesn't allow for the more concurrent subscriber behaviour. I have some ideas on improving it. I think, that the improved implementation with locking reduces...

@SystemFw I went ahead a bit and just created the benchmark of the `queue-based` topic implementation. I took liberty of using the code submitted by @vladimir-popov, as a reference point....