Akka-Stream implementation slower than single threaded implementation

Question

UPDATE FROM 2015-10-30

---

based on Roland Kuhn Awnser:

Akka Streams is using asynchronous message passing between Actors

Answer 1

In addition to Roland's explanation, which I agree with fully, it should be understood that akka Streams are not just a concurrent programming framework. Streams also provide back pressure which means Events are only generated by the Source when there is demand to process them in the Sink. This communication of demand adds some overhead at each processing step.

Therefore your single-thread and multi-thread comparison is not "apples-to-apples".

If you want raw multi-threaded execution performance then Futures/Actors are a better way to go.

Answer 2

Akka Streams is using asynchronous message passing between Actors to implement stream processing stages. Passing data across an asynchronous boundary has an overhead that you are seeing here: your computation seems to take only about 160ns (derived from the single-threaded measurement) while the streaming solution takes roughly 1µs per element, which is dominated by the message passing.

Another misconception is that saying “stream” implies parallelism: in your code all computation runs sequentially in a single Actor (the map stage), so no benefit can be expected over the primitive single-threaded solution.

In order to benefit from the parallelism afforded by Akka Streams you need to have multiple processing stages that each perform tasks of >1µs per element, see also the docs.