3.x: Performance improvements (tracking issue)

[akarnokd]

I assembled a fresh evaluation of RxJava 1, 2 and Reactor 3.2 performance under various usages and found the following deficiencies in RxJava 2.

• Flowable.empty() appears to be consuming a lot of memory.
• See if a non-trampolining Schedulers.from could improve async/pipeline performance.
• Check why Observable.blockingLast has 30% more overhead than its Flowable counterpart.
• Check why there is a lot more overhead with ReplayProcessor and ReplaySubject compared to v1.
• Check why there is a lot more overhead with UnicastProcessor and UnicastSubject compared to v1.
• Check why Observable.fromArray is somewhat slower with longer sources than Flowable.
• Check why Observable.fromIterable is slower with longer sources than Flowable.
• Optimize Observable.concatMap for scalar inner sources.
• Check why Flowable.flatMapIterable is drastically slower than Observable and Reactor's version in just/range/crossmap scenarios.

[ayudovin]

Hi, I'd like to check why you have a performance problem in this moment
if I had found the reason that Would I have opportunity to create a merge request with solution ?

[akarnokd]

@ayudovin Sure.

[akarnokd]

Flowable.empty() was simply a measurement anomaly due to class loading.

[SergejIsbrecht]

@akarnokd , how do you want to measure it? As you are aware certainly aware, there are different implementations C1, C2 (Hotspot), ART, Graal. Which compilation stage do you want to perform better and which implementation should be the baseline?

I would suggest using OpenJDK 11 with C2 Hotspot with default setting tested via JMH.

Furthermore, which metric should be improved? Allocation-Rate/ Operations per Second?

[akarnokd]

You can try that. Ops/second is the usual measure for us.

[MaratCrash]

@akarnokd hi, is it actual issue for now?

[akarnokd]

Different JVM versions give different results and I don't see any clear optimizations to make them better across. I'll close it for now.