问题描述
我有一种预感，对于RxJava中高度计算的并行化任务，传统的 ExecutorService 将比 Scheduler 。
I had a hunch that for highly computational, parallelized tasks in RxJava, a traditional ExecutorService would be faster than a Scheduler.
我有一个理论认为这段代码
I had a theory that this code
Observable<MyItem> source = ...
source.flatMap(myItem -> myItem.process().subscribeOn(Schedulers.computation()))
.subscribe();
运行速度比这个慢
final ExecutorService svc = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors() + 1);
Observable<MyItem> source = ...
source.flatMap(myItem -> myItem.process().subscribeOn(Schedulers.from(svc)))
.finallyDo(svc::shutdown)
.subscribe();
我将这两种方法与我在工作中进行的典型并行处理进行了比较，得到了以下结果。
I compared these two approaches with a typical parallel process I do at work, and I got the following results.
EXECUTOR
START: 2016-01-25T09:47:04.350
END: 2016-01-25T09:48:37.181
TOTAL TIME (SEC): 92
COMPUTATION SCHEDULER
START: 2016-01-25T09:50:37.799
END: 2016-01-25T09:54:23.674
TOTAL TIME (SEC): 225
所以我的粗略测试显示传统的 ExecutorService 比 Scheduler 快得多用于计算。
So my rough testing has shown the traditional ExecutorService is much faster than a Scheduler for computation.
这些结果是否有原因？ RxJava调度程序是否未针对并行化进行优化？我的印象是计算调度程序使用的线程比执行程序少。
Is there a reason for these results? Are RxJava schedulers just not optimized for parallelization? I've gotten the impression that computation schedulers use lesser threads than Executors.
推荐答案
我做了几次测试并发现创建了自己的 ExecutorService 实际上可以提高并行化性能。 。
I did several tests and discovered that creating your own ExecutorService can in fact increase parallelization performance. I wrote a blog post on it here.
这篇关于RxJava - 调度程序与ExecutorService？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！