Hi, I'm trying to figure out to what exactly does ...
# coroutines
ł
Hi, I'm trying to figure out to what exactly does the Kotlin coroutine usage in this blogpost by Adam Warski of SoftwareMill compile to. I've went as far as decompiling bytecode in Idea to try and understand how and why we see the results we see. Kotlin coroutines take about 750ms to complete this task and everything else takes several seconds including Loom and all Scala's effect libraries. We've been able to figure out that Kotlin runtime uses a single thread in this example so we've also limited threading to single thread in all other platforms but there's still at least 5x difference that we can't explain. Is anyone able to explain what does
launch { }
do in this scenario? Are there some very specific optimizations that basically rewrite this so that these two coroutines schedule each other cooperatively? edit: btw congratulations on these marvelous results!
👀 1
c
would suggest running a profiler through the various implementations to identify where the hotspots are (code paths, locks, etc). Its hard to speculate on performance with complex concurrency constructs.
ł
Yeah, I took a look into async profiler output, found out that there's an event loop associated with
runBlocking
that apparently skips all the synchronization and it kinda explains what happened, I modified the code to use
launch(Executors.newSingleThreadExecutor().asCoroutineDispatcher()) {
and now all runs take around 20s so yeah, I'll talk with Adam to provide an explanatory clause because people on twitter are already picking on that post as it's comparing apples to oranges. It kinda is but the point of the experiment was to find the fastest possible implementation for channels in Loom-based structured concurrency library ox and not to compare things.
👍 1