Pavel Chlupacek

update: Somehow current implementation when Semantic lock is put in place is always using single thread. This should not be the case, as the F.start is used on completion of...

update: these are top contributors to running a lot of subscribers under pub/sub: Neither of them is related to concurrency. My theory is that cost of looking up the subscriber...

Just a quick update on this one. I am still experimenting with the ways how to tackle on this one. It seems that i may need to touch pubsub strategy...

This is unfortunatelly worst case acenario for fs2. The Stream.eval part of code unfortunatelly has that much overhead that it will never get in par with io here. try broadcast...

To clarify, there are two things that this really exposes : - `Stream.eval`, in interruptible stream composition (that is essentially any concurrent one) is racing evaluation of `F` for every...

My earlier measurement of similar use cases showed in such cases relatively low fs2 overhead, when using `balance`.

@svalaskevicius, Ok I went ahead and tried a play a bit with your code. The resulting gist I have used, is very similar to yours (only using vector an balance)...

disclaimer - the laziness as the reason is over simplification here, you could write in IO/Future program that will be lazy and will still perform better compare to fs2. Also,...

Lastly my theory behind the gaps in thread usage is actually the better distribution and concurrency of fs2 over your Future and IO implementations. If you look carefully, the threads...

@svalaskevicius I am quite sure they do not (mean threads work and they stop all immediately). There is a time, when you need to collect the work from all the...