Skip to content
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 6 commits into from
Oct 23, 2024

Conversation

BalmungSan
Copy link
Contributor

@BalmungSan BalmungSan commented Feb 10, 2024

Since the reactive-streams spec mentions that all calls must be done "serially" these changes optimize the tight loop of multiple consequential onNext calls.


Benchmark results

Before the optimization

Benchmark (fibers) (iterations) Mode Cnt Score Error Units
FlowInteropBenchmark.fastPublisher 1000 1024 thrpt 20 25.938 ± 0.306 ops/s
FlowInteropBenchmark.fastPublisher 1000 5120 thrpt 20 6.519 ± 0.015 ops/s
FlowInteropBenchmark.fastPublisher 1000 10240 thrpt 20 3.201 ± 0.168 ops/s
FlowInteropBenchmark.fastPublisher 1000 51200 thrpt 20 0.680 ± 0.013 ops/s
FlowInteropBenchmark.fastPublisher 1000 512000 thrpt 20 0.062 ± 0.001 ops/s

After the optimization

Benchmark (fibers) (iterations) Mode Cnt Score Error Units
FlowInteropBenchmark.fastPublisher 1000 1024 thrpt 20 63.846 ± 0.094 ops/s
FlowInteropBenchmark.fastPublisher 1000 5120 thrpt 20 22.314 ± 0.107 ops/s
FlowInteropBenchmark.fastPublisher 1000 10240 thrpt 20 12.662 ± 0.028 ops/s
FlowInteropBenchmark.fastPublisher 1000 51200 thrpt 20 2.736 ± 0.012 ops/s
FlowInteropBenchmark.fastPublisher 1000 512000 thrpt 20 0.275 ± 0.002 ops/s

Analysis

For only 2 chunks of 512 elements the improvements were almost 2.5 times better.
For 20 chunks, the improvements were almost 4 times better.
But the improvements for 1000 chunks were just 4.4 times better.

It seems then that in a fully sequential and CPU-bound Publisher, the new Subscriber 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.


Lies, Damn Lies, and Benchmarks

@BalmungSan BalmungSan force-pushed the optimize-flow-interop branch from 72b0be9 to 8234158 Compare February 12, 2024 17:14
@@ -109,6 +109,7 @@ private[flow] final class StreamSubscription[F[_], A] private (
// if we were externally canceled, this is handled below
F.unit
}
.mask
Copy link
Contributor Author

@BalmungSan BalmungSan Feb 12, 2024

Choose a reason for hiding this comment

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

Related to #3384

@BalmungSan BalmungSan force-pushed the optimize-flow-interop branch from 05418a2 to d565f2e Compare October 19, 2024 18:38
@BalmungSan BalmungSan requested a review from armanbilge October 20, 2024 13:33
@BalmungSan BalmungSan force-pushed the optimize-flow-interop branch from d565f2e to 1c0ba9a Compare October 21, 2024 21:33
@BalmungSan BalmungSan requested a review from armanbilge October 21, 2024 21:33
@BalmungSan BalmungSan force-pushed the optimize-flow-interop branch from 1c0ba9a to fe97a74 Compare October 21, 2024 21:56
@BalmungSan BalmungSan force-pushed the optimize-flow-interop branch from fe97a74 to 58bfa07 Compare October 21, 2024 22:28
@BalmungSan BalmungSan requested a review from armanbilge October 22, 2024 03:39
@armanbilge armanbilge changed the title Optmize interop.flow.StreamSubscriber.onNext Optmize interop.flow.StreamSubscriber.onNext Oct 23, 2024
@armanbilge armanbilge merged commit 8d11163 into typelevel:main Oct 23, 2024
15 checks passed
@BalmungSan BalmungSan deleted the optimize-flow-interop branch October 23, 2024 00:25
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.

3 participants