:tada: switching from `IOs parTraverse` to `fx-cor...
# arrow
j
🎉 switching from
IOs parTraverse
to
fx-coroutines parTraverse
seem to gives me about 20 to 26 percent performance gain ! ...to authors & experienced users of fx-coroutines: is that your observation too ? (and for sure it is much more concise and elegant 🙂 )
🎉 6
t
That is on point. Around 25% here. And of course no suspend <=> IO transitions 🙂. arrow
👍 1
y
IIRC performance was one of the reasons for the transition. The other, of course, was to be more idiomatic
t
You kinda inspired me to update one older workflow from IO to fx-coroutines. I'm getting 60 - 90% perf increase o.O. Granted there might have been some weirdness going on 😄. But still
j
I forgot to mention that I assume that IO pool size was the same in 0.10.5 and 0.11.0, didn’t verify yet...
r
Arrow Fx Coroutines is currently the fastest IO we have benchmarked compared to Scala and our own thanks to suspension and the great work Simon did on the library.
❤️ 1
Now we are further abstracting the same model to other algebras based on shift / reset and the work Jannis, Simon and I have been exploring to eliminate old hacks and potentially get rid of kinds all around
If you are using IO you should migrate to arrow Fx Coroutines. I don't feel flashing benchs here is appropriate but trust us or run your own
They are also available in the repo
Any library that offers an IO based on a data type and a fold run loop regardless of the Lang is at disadvantage unless it uses macros or codegen since the Kotlin compiler specializes user functions to the suspension loop with minimal allocations. It's a piece of art what's in the Kotlin compiler in suspension to avoid allocations and provide a fast runtime.
s
I really want to. But I am desperate. I can’t use snapshot version in prod 😔
r
Release of 0.11 should be around the corner based on what I heard from @Rachel yesterday on what's missing. 😊
👌 1
😍 2