Benchmark 9/19

# See the most recent comparison in #7.

# Comparative benchmark
- RxJava 1.2 (9/17)
- RxJava 2.0.0-DP0-SNAPSHOT (9/15)
- Reactor Core 3.0.3-BUILD.SNAPSHOT (9/19)

Environment:
- i7 4790 stock settings
- Windows 7 x64
- Java 8u102
- JMH 1.13
- `-XX:MaxInlineLevel=20`

Green is good, red is not so good.
- JMH-Compare-GUI workspace file with the data: https://gist.github.com/akarnokd/6550d42f4a4fb7bbead0ea3afdbbf42e
## Subscribe to a simple source


Just comparing 1.x and 2.x


**Remarks**:
- Subscribing to any type in 2.x has lower overhead than 1.x.
## Streaming multiple values (synchronous)


**Remarks**:
- There seems to be some extra overhead in the backpressured `concatMapXRange` (both 2.x and Reactor).
- Also `flatMapJust` has extra overhead for all 2.x types (could be unavoidable atomics).
- `flatMapXRange` 1M (which is `flatMapJust` 1M essentially) suffers the same overhead.
- 2.x `Observable.flatten` is not optimized yet and delegates to plain `flatMap`
- Otherwise, nice improvements all over the board.
## Asynchronous and pipelined streaming


**Remarks**:
- There seems to be some extra overhead or missing optimization from Flowable async 1.
- 2.x Observable lack of optimization (1-case) and likely buffer-bloat in longer streams.
- Generally not bad, but such benchmarks can be hectic (on Windows especially).
## Memory usage


**Remarks**:
- Generally half the memory usage.
- `empty()` seems to be occupying too much memory as if there 1M unique empty() instance.
- `Behavior` and `Unicast` seem to occupy double the memory for some reason.
## Subject/Processor synchronous streaming


**Remarks**:
- `Async`, `Publish` and small `Replay` is definitely faster in 2.x
- Larger `Replay`, any `Unicast` and any `Behavior` are half-to-quarter slower for some unknown reason.
## Blocking for an item (or completion)




**Remarks**:
- All seem to better at blockingly retrieve one element, except 2.x `Observable` for some reason.
- Reactor is optimized on blocking `empty()` retrieval
# Reactor 3 vs RxJava 2
- They have the same underlying architecture style.
- Operator internals are practically the same for most `Flowable`/`Flux` types.
- **Reactor** delegates some of its `Mono` operators to `Flux` operator internals.
- **Reactor** has more operators fusion-enabled, **RxJava** has most important operators fusion-enabled, its `Observable` has not been extensively optimized though.
- **Reactor** uses queue-suppliers, **RxJava** creates specific queues in operators.
- **Reactor** uses atomic field updaters, **RxJava** extends `AtomicXXX` classes but otherwise uses AtomicXXX instance fields.
- **Reactor** has only an `onAssembly` hook, **RxJava** has a subscribe-time hook and indirection on top of `onAssembly` hook.
## Subscribing


**Remarks**:
- Reactor uses a weaker form of backpressure in `just` and thus slightly better.
## Streaming synchronously


**Remarks**:
- Most operators are within the +/- 5% error margin.
- Reactor's `flatMap` seems to be slightly faster (5-15%)
- Reactor's `flatten` seems to be reasonably faster (1.5x to 2x).
- Reactor's `iterable` seems to be slightly slower (5-15%)
## Async streaming


**Remarks**:
- The `async` benchmark is a bit hectic, inconclusive which is better
- Reactor likes longer `pipeline`d streams but dislikes shorter `pipeline`d streams.
## Memory use


**Remarks**:
- Inconclusive, Reactor has more overhead in places and less in others.
- Reactor's processors are more compacted but leak API.
- Reactor has some drastic `Replay` overhead.
## Processor overhead


**Remarks**:
- Reactor is faster in general but slightly slower in large `Replay` and `Unicast`
## Blocking


**Remarks**:
- Reactor is optimized for blocking on an `empty()`


**Remarks**:
- Blocking for the first element is the same.


**Remarks**:
- Blocking for the last element is slower in Reactor.
# Conclusion
- RxJava 2.x is generally better in terms of performance and memory utilization than 1.x; most lower performing components can be optimized further.
- Reactor is generally 10-50% better in a Java 8 environment due to more inlined nature and even fewer allocations than RxJava 2.