5 ms·

The readme as well as the homepage mention "100x the performance of Scala's Future" What makes scala's Future perform poorly, and how does zio avoid that? I fe

by abeppu 6y ago

The readme as well as the homepage mention "100x the performance of Scala's Future" What makes scala's Future perform poorly, and how does zio avoid that? I feel like they tried really hard to present the project in terms of what it can do for you, and I get that. But if there's some real conceptual insight underlying that 100x improvement, where could I read about that?

deleted 6y ago
[deleted]
ibraheemdev 6y ago
> zio has excellent performance, featuring a hand-optimized, low-level interpreter that achieves zero allocations for right-associated binds, and minimal allocations for left-associated binds. > The benchmarks [1] project may be used to compare IO with other effect monads, including Future (which is not an effect monad but is included for reference), Monix Task, and Cats IO. > As of the time of this writing, IO is significantly faster than or at least comparable to all other purely functional solutions. https://zio.dev/docs/overview/overview_performance https://zio.dev/docs/overview/overview_performance [1] https://github.com/zio/zio/tree/master/benchmarks https://github.com/zio/zio/tree/master/benchmarks
dwohnitmok 6y ago
Scala's Futures constantly dip back into their ExecutionContext even when unnecessary; basically every single method on a Future causes it to go back to the ExecutionContext. This means they can incur bookkeeping or at worst thread switching overhead for no good reason. For example, `map`ping over a completed Future has absolutely no need to go back to the ExecutionContext. Even `flatMap`ping multiple Futures together doesn't necessarily need an ExecutionContext if you offer a separate API to allow `Future`s to switch between threads (this also means that Futures must be delayed and can't run immediately). These are the big things that make things like ZIO and cats-effect IO faster (there are then other smaller things that differentiate those two from each other).
UglyGenius 6y ago
As it already has been mentioned - Future's poor performance is mostly due redundant context switches on pretty much any operation. If you do `future.map((i: Int) => i + 1)` it can be executed on a different thread, which doesn't make much sense. It was the case in 2.11 stdlib and they're doing lots of improvements in this area, but Future still lags behind all widely-used "IO monads". But put aside performance, any day of the week I'd choose ZIO (or Cats Effect IO or Monix Task) over Future even if ZIO was 10x slower. Amount of safety and composability "IO monads" give is outstanding.

by abeppu 6y ago

deleted 6y ago

[deleted]

ibraheemdev 6y ago

> zio has excellent performance, featuring a hand-optimized, low-level interpreter that achieves zero allocations for right-associated binds, and minimal allocations for left-associated binds. > The benchmarks [1] project may be used to compare IO with other effect monads, including Future (which is not an effect monad but is included for reference), Monix Task, and Cats IO. > As of the time of this writing, IO is significantly faster than or at least comparable to all other purely functional solutions. https://zio.dev/docs/overview/overview_performance https://zio.dev/docs/overview/overview_performance [1] https://github.com/zio/zio/tree/master/benchmarks https://github.com/zio/zio/tree/master/benchmarks

dwohnitmok 6y ago

Scala's Futures constantly dip back into their ExecutionContext even when unnecessary; basically every single method on a Future causes it to go back to the ExecutionContext. This means they can incur bookkeeping or at worst thread switching overhead for no good reason. For example, `map`ping over a completed Future has absolutely no need to go back to the ExecutionContext. Even `flatMap`ping multiple Futures together doesn't necessarily need an ExecutionContext if you offer a separate API to allow `Future`s to switch between threads (this also means that Futures must be delayed and can't run immediately). These are the big things that make things like ZIO and cats-effect IO faster (there are then other smaller things that differentiate those two from each other).

UglyGenius 6y ago

As it already has been mentioned - Future's poor performance is mostly due redundant context switches on pretty much any operation. If you do `future.map((i: Int) => i + 1)` it can be executed on a different thread, which doesn't make much sense. It was the case in 2.11 stdlib and they're doing lots of improvements in this area, but Future still lags behind all widely-used "IO monads". But put aside performance, any day of the week I'd choose ZIO (or Cats Effect IO or Monix Task) over Future even if ZIO was 10x slower. Amount of safety and composability "IO monads" give is outstanding.