Performance of mutlitheading in RX vs Theads vs Executors

Java Executor services uses Threads and RxKotlin uses ExecutorServices. So all of these are same in the background. The difference is software architecture. So if you choose the best architecture be integrated with your code it will work best and do the job correctly. Simple is the best.

If you have a event based or observable based architecture and you are trying to implementing a new library to work with event based operations or jobs you could write wrong steps about job separation or timing. Use RxKotlin and don't invent the wheel again.

If your work not about events or observable pattern and you just need to do parallel jobs just use the Executor services. The RxKotlin will be over engineering. When you use RxKotlin in this situation you need to do more thing then you need.

So i think the question is not the speed in this situation, the architecture is.

KotlinRx itself uses executors, except it has two pre-created thread pools under Schedulers.io() (unbounded) and Schedulers.computation() (bounded by the number of cores) and doesn't spin up a new one each time as your suggested code does. Which you obviously can do manually too:

private val executor = Executors.newCachedThreadPool() // equivalent to io()

fun <T> waitAll(tasks: List<Callable<T>>): List<T> {
    return executor.invokeAll(tasks).map {
        it.get()
    }
}

This should be better than creating a thread for each task, generally speaking, by allowing to reuse existing threads, but depends on your usage.

coroutines is (IMO) more suitable for dealing with background/ui-thread communication (i.e Android etc)

Whether coroutines are useful for this very much depends on what you have inside your tasks. A blocking API (e.g. JDBC)? They aren't. An async one (e.g. Retrofit)? They are.