10000 Use an improved eq in `FiberRefs` and add shortcut for `join` by kyri-petrou · Pull Request #9100 · zio/zio · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Use an improved eq in FiberRefs and add shortcut for join #9100

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Aug 13, 2024

Conversation

kyri-petrou
Copy link
Contributor

One of the things I didn't account for in #8989 is that eq on boxed primitives returns false even if the underlying integer is the same 🫠. The fix is rather simple; typecheck the value and if it's a java.lang.Number then unbox it and compare it (via BoxesRunTime.equalsNumObject.

While I was doing this, I thought to also do the following:

  1. To add an assertion that our now improvedEq produces the same outcome as == (note that this assertion does not exist in the published artifacts!).
  2. To add a shortcut when we join on 2 FiberRefs which are equal according to eq. This is a very common case especially when we do ZIO.foreachPar, since in most cases we won't be modifying any of the FiberRefs in any of the effects run in parallel. Therefore, inheritAll then becomes much cheaper, which overall improves the performance of foreachPar quite substantially:

series/2.x

[info] Benchmark                                      Mode  Cnt     Score    Error  Units
[info] ForeachParDiscardBenchmark.foreachParDiscard  thrpt    5  1179.541 ± 42.125  ops/s

PR

[info] Benchmark                                      Mode  Cnt     Score     Error  Units
[info] ForeachParDiscardBenchmark.foreachParDiscard  thrpt    5  1463.919 ± 104.970  ops/s

Note that in some rare cases, the ZEnvironment.Patch.diff will return a Patch that when applied, it will result having the same services in the environment. To avoid this, I added a guard against this by checking that the resulting ZEnvironment is indeed different (as determined by ==). I think that since our equals method on ZEnvironment is fairly well optimized, I'm thinking it's better not to risk destroying the FiberRefs optimizations and perform this check. Thoughts?

@kyri-petrou kyri-petrou requested a review from jdegoes August 12, 2024 17:03
* method shows up in benchmarks, make sure to compile the code with the
* envvar set.
*/
private def improvedEq[A <: AnyRef](x: A, y: A): Boolean = {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not great, but: eqWithBoxedNumericEquality?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done :)

ghostdogpr
ghostdogpr previously approved these changes Aug 13, 2024
@kyri-petrou
Copy link
Contributor Author

My apologies @ghostdogpr, I ended up making some final adjustments after your review:

  • Ended up moving the assertion to be run only in fork. I think that's the most important one, and I think it's probably better long-term to have it there since the errors in join can some times be really difficult to debug. For most usecases, we don't alter the FiberRefs in forked fibers so join should most of the time return the same object
  • Did some minor changes to methods in FiberRef to use ZIO.identifyFn and ZIO.secondFn

Copy link
Member
@jdegoes jdegoes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent work, as always! Love the huge foreachPar speedup. ❤️

@jdegoes jdegoes merged commit ba0b1ef into zio:series/2.x Aug 13, 2024
21 checks passed
@kyri-petrou kyri-petrou deleted the use-improved-eq-in-fiber-refs branch August 13, 2024 11:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0