The first important point is to not generalize. That’s like going outside, seeing a black Ferrari, and then concluding that all Ferrari’s are black.
In your particular code, you call flow, map and string, so at the best you can conclude that some of the operations in flow, map and string are not as performant as you would expect. Especially because this type of benchmark is about executing some operations millions of times.
It may also be that you are using the wrong tool to solve the problem, in this case flow. There is a cost where coordinating across multiple cores becomes worth it and you may not have reached it.
There is also the fact that Erlang/Elixir will be slower than Java. If you need a language that is as fast as Java, then you should pick Java or maybe C. There are other mainstream languages that are slower than Elixir too and that is not a deterrent for many using those languages.
Everyone gave a lot of feedback on how the code can be improved but that’s ultimately hard to do without having the data. If I have to guess, I would say that the map operation is the one slowing everything down. Because maps are immutable, this kind of hot loop generates a lot of garbage. This is also covered in the performance section of the Flow documentation: Flow — Flow v1.2.4
And before someone starts to worry about maps performance, it is worth saying that I have been programming in Elixir for almost 6 years and the only time I had to replace a map by a mutable data structure because of performance was exactly when working on GenStage + Flow.
