Use Exit.succeed in more places
#9418
Conversation
| @@ -970,7 +970,7 @@ sealed trait ZIO[-R, +E, +A] | |||
| * Returns an effect whose success is mapped by the specified `f` function. | |||
| */ | |||
| def map[B](f: A => B)(implicit trace: Trace): ZIO[R, E, B] = | |||
| flatMap(a => ZIO.succeed(f(a))) | |||
There was a problem hiding this comment.
this will greatly reduce the instances of ZIO.Sync... should be interesting to see if this impacts runtime performance. Does FiberRuntime always prioritize ZIO.flatMap?
There was a problem hiding this comment.
At the moment, the FiberRuntime runloop checks first whether the effect is ZIO.Sync and then Exit. However, after all these changes to use Exit a lot more, I'm contemplating to move Exit to be the first one to be checked. WDUT?
There was a problem hiding this comment.
It's hard to say. I figure 90%+ of user code is probably not explicitly using Exit, but I could be wrong. I do think we should generally optimized for deeply nested ZIOs (via map/flatMap) as usercode is often not optimized to reduce that.
It would be cool if we could get stats on suspension depth and ask users to collect this information...
| override final def map[B](f: A => B)(implicit trace: Trace): ZIO[Any, E, B] = | ||
| mapExit(f) | ||
|
|
There was a problem hiding this comment.
@hearnadam since you already reviewed just wanted to point out that I made this change (also with fold) since your last review. I think this overriding is no longer required because we already override flatMap to produce an exit. This allows us to make the map and fold methods final on ZIO which means the JVM can apply better optimizations / inlining as the method is no longer overwritten.
It does result in slightly more allocations in cases that map / fold is used on an Exit, but to be honest I think those cases not very common and we can always use mapExit / foldExit on them.
AFAICT all these places are safe to use
Exit.succeedas the values / functions are already suspended in another effect