-
Notifications
You must be signed in to change notification settings - Fork 21
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
Benchmark 9/19 #2
Comments
There's room for improvement in reactor I think given some latest design improvements but this is a massively complete report, congrats @akarnokd ! |
great info, that makes me even more wanting to move the couchbase SDK over to 2.x at some point, but still not sure how to figure out a smooth migration path :) |
Hi |
These are operations per second, larger is better tables. There is a baseline value chosen in each table and the other columns are measured relative to it. Green background indicate improvements, red mean worse performance.
In the first table the, it shows how many times various, simple reactive types can be subscribed to in a second.
There isn't one. They are simple sources with 0 or 1 element, depending on the type. Later tables feature longer sequences as those show how the infrastructure overhead is amortized over many items. |
@akarnokd |
See the most recent comparison in #7.
Comparative benchmark
Environment:
-XX:MaxInlineLevel=20
Green is good, red is not so good.
Subscribe to a simple source
Just comparing 1.x and 2.x
Remarks:
Streaming multiple values (synchronous)
Remarks:
concatMapXRange
(both 2.x and Reactor).flatMapJust
has extra overhead for all 2.x types (could be unavoidable atomics).flatMapXRange
1M (which isflatMapJust
1M essentially) suffers the same overhead.Observable.flatten
is not optimized yet and delegates to plainflatMap
Asynchronous and pipelined streaming
Remarks:
Memory usage
Remarks:
empty()
seems to be occupying too much memory as if there 1M unique empty() instance.Behavior
andUnicast
seem to occupy double the memory for some reason.Subject/Processor synchronous streaming
Remarks:
Async
,Publish
and smallReplay
is definitely faster in 2.xReplay
, anyUnicast
and anyBehavior
are half-to-quarter slower for some unknown reason.Blocking for an item (or completion)
Remarks:
Observable
for some reason.empty()
retrievalReactor 3 vs RxJava 2
Flowable
/Flux
types.Mono
operators toFlux
operator internals.Observable
has not been extensively optimized though.AtomicXXX
classes but otherwise uses AtomicXXX instance fields.onAssembly
hook, RxJava has a subscribe-time hook and indirection on top ofonAssembly
hook.Subscribing
Remarks:
just
and thus slightly better.Streaming synchronously
Remarks:
flatMap
seems to be slightly faster (5-15%)flatten
seems to be reasonably faster (1.5x to 2x).iterable
seems to be slightly slower (5-15%)Async streaming
Remarks:
async
benchmark is a bit hectic, inconclusive which is betterpipeline
d streams but dislikes shorterpipeline
d streams.Memory use
Remarks:
Replay
overhead.Processor overhead
Remarks:
Replay
andUnicast
Blocking
Remarks:
empty()
Remarks:
Remarks:
Conclusion
The text was updated successfully, but these errors were encountered: