-
Notifications
You must be signed in to change notification settings - Fork 604
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
Optmize interop.flow.StreamSubscriber.onNext
#3387
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BalmungSan
force-pushed
the
optimize-flow-interop
branch
from
February 12, 2024 17:14
72b0be9
to
8234158
Compare
BalmungSan
commented
Feb 12, 2024
@@ -109,6 +109,7 @@ private[flow] final class StreamSubscription[F[_], A] private ( | |||
// if we were externally canceled, this is handled below | |||
F.unit | |||
} | |||
.mask |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related to #3384
BalmungSan
commented
Mar 29, 2024
benchmark/src/main/scala/fs2/benchmark/FlowInteropBenchmark.scala
Outdated
Show resolved
Hide resolved
benchmark/src/main/scala/fs2/benchmark/FlowInteropBenchmark.scala
Outdated
Show resolved
Hide resolved
benchmark/src/main/scala/fs2/benchmark/FlowInteropBenchmark.scala
Outdated
Show resolved
Hide resolved
armanbilge
reviewed
Sep 30, 2024
benchmark/src/main/scala/fs2/benchmark/FlowInteropBenchmark.scala
Outdated
Show resolved
Hide resolved
benchmark/src/main/scala/fs2/benchmark/FlowInteropBenchmark.scala
Outdated
Show resolved
Hide resolved
BalmungSan
force-pushed
the
optimize-flow-interop
branch
from
October 19, 2024 18:38
05418a2
to
d565f2e
Compare
armanbilge
reviewed
Oct 21, 2024
benchmark/src/main/scala/fs2/benchmark/FlowInteropBenchmark.scala
Outdated
Show resolved
Hide resolved
BalmungSan
force-pushed
the
optimize-flow-interop
branch
from
October 21, 2024 21:33
d565f2e
to
1c0ba9a
Compare
armanbilge
reviewed
Oct 21, 2024
benchmark/src/main/scala/fs2/benchmark/FlowInteropBenchmark.scala
Outdated
Show resolved
Hide resolved
BalmungSan
force-pushed
the
optimize-flow-interop
branch
from
October 21, 2024 21:56
1c0ba9a
to
fe97a74
Compare
BalmungSan
force-pushed
the
optimize-flow-interop
branch
from
October 21, 2024 22:28
fe97a74
to
58bfa07
Compare
armanbilge
changed the title
Optmize interop.flow.StreamSubscriber.onNext
Optmize Oct 23, 2024
interop.flow.StreamSubscriber.onNext
armanbilge
approved these changes
Oct 23, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since the
reactive-streams
spec mentions that all calls must be done "serially" these changes optimize the tight loop of multiple consequentialonNext
calls.Benchmark results
Before the optimization
After the optimization
Analysis
For only
2
chunks of512
elements the improvements were almost2.5
times better.For
20
chunks, the improvements were almost4
times better.But the improvements for
1000
chunks were just4.4
times better.It seems then that in a fully sequential and CPU-bound
Publisher
, the newSubscriber
is roughly 4 times more efficient. As long as the chunk size is adequate, and there are enough chunks to flatten the overhead of the general machinery.Overall, I would say this optimization looks great, even if realistic use cases won't get such a big increase, it is likely the effects will be noticeable.