5 ms·
I'm not sure a cached pool of OS threads is comparable in this way to coroutines. The author also isn't doing any I/O bound work... or... any work at all? You
by sgammon 3y ago
I'm not sure a cached pool of OS threads is comparable in this way to coroutines. The author also isn't doing any I/O bound work... or... any work at all?
You can schedule coroutines over a threadpool. From the author's code, I'm not even sure this was accounted for in the benchmark. If they are using a threadpool and vanilla coroutines, without specifying where they are scheduled, yes, of course it won't start up a pool of threads for you and be as fast as a pool of threads. It would be terrible if it did that by default.
- tadfisher 3y agoIt does do this by default; Dispatchers.Default wraps a ThreadPoolExecutor with n threads, where n is the number of logical CPU cores. This is used for computation-bound work. The other built-in Dispatcher instances are Dispatchers.IO, with an unbounded thread pool for I/O-bound work; and Dispatchers.Main, which schedules on your platform's UI thread.
- jillesvangurp 3y agoThe IO dispatcher is a fixed size threadpool of 64 threads or the number of cpu cores (whichever is larger). You can use the kotlinx.coroutines.io.parallelism system property to override the default of 64.
- sgammon 3y agoThat would require `withContext(Dispatchers.IO)`...
- sgammon 3y agoIs this the default on all platforms, Android, or JVM?