RxJava - switchMap（）の切り替えが遅いのはなぜですか？

Question

私は職場で興味深い発見をしました。私は、RxJavaの指導者の一人がそれを説明できることを願っています。私はRxJava 1.2.4を使用しています。

私はRxJavaFXを使用して、JavaFX TableView（これらはJavaFXスレッド上で出力されます）からテーブル選択イベントを発生させ、switchMap()に入れて、それぞれに対して高価なプロセスを開始しました。私はをsubscribeOn()と一緒に使用して並行性を活用するだけでなく、複数の選択をすばやく行うと、前の要求がキャンセルされ、次に最新のものが次に開始されます。

tableSelectionEvents.switchMap { 
     runExpensiveProcess(it) 
       .subscribeOn(Schedulers.io()) 
       .flatMap { anotherExpensiveProcess(it) } 
       .toList() 
    }.observeOn(JavaFxScheduler.getInstance()).subscribe { 
     backingList.setAll(it) 
    } 

しかし、私はJavaFXのスレッドは、まだかなりの量の作業をしていた意味、選択を行ってJavaFXのUIが恐ろしくラグ気づきました。これは私がswitchMap()の中でSchedulers.io()を使って別のスレッドで作業をオフロードしたと思ったために私に困惑しました。しかし何かが続いていた。

私は勘違いしての直前にobserveOn(Schedulers.io())を入れました。今はすべてが完璧に走り、ラグは全くありません。私の理論は、入ってくるスレッド（もともとはJavaFXスレッド、現在はIOスレッド）がswitchMap()内の最後のサブスクリプションをキャンセルするには相当な作業をしなければならないということです。これにより、JavaFXスレッドは、キャンセルを実行してUIをフリーズするのにかなりの時間を費やしました。

switchMap()の中でunSubscribe()と呼びますか？

Answer 1

私は別のフォーラムでJake Whartonから助けを得ました。彼は私がすでに疑うようになったことを強調しました。一部のサブスクリプションは、他のサブスクリプションよりも高価です。この場合、私はRxJava-JDBCを使用しているので、処理する必要のあるオーバーヘッドが多くなり、JavaFXスレッドがこれを実行するようになりました。

彼はまた、これはunsubscribeOn()オペレータのためのものだと私に言った。サブスクリプションを実行するためのスケジューラを指定することができます。

tableSelectionEvents.switchMap { 
     runExpensiveProcess(it) 
       .subscribeOn(Schedulers.io()) 
       .flatMap { anotherExpensiveProcess(it) } 
       .toList() 
       .unsubscribeOn(Schedulers.io()) 
    }.observeOn(JavaFxScheduler.getInstance()).subscribe { 
     backingList.setAll(it) 
    }