i feel that coroutines have the great disadvantage...

# coroutines

[thana]

i feel that coroutines have the great disadvantage, that ehy cmopletly spoil the stack traces. so currenyly im profiling an application and all i see is that invokeSuspend takes a considerbale amount of time. How do you cope with this situation? can we expect the situation will improve when the jvm itself supports suspendable methods?

[kevinherron]

have you already read this? https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/debugging.md

[thana]

yes, but all it does in my eys is slightly improving the situation by glueing together some stack traces.
In fact they are still spoiled because the whole logic is rewritten by coroutines

[Dico]

Are you suggesting that this problem is unique to coroutines?

[thana]

yes

[gildor]

Project Loom and JVM support of coroutines most probably will be indifferent for Kotlin Coroutines, Kotlin Coroutines are compile time transformation, so there is no runtime magic.
But for sure some optimization may be done in future

It's indeed problem how to profile dispatching of asynchronous code on coroutines, but you should try to investigate and report your case if you see some particular problem in implementation

The easiest solution is to use blocking code for hot spots of your app, do less dispatching, it's also true for any asynchronous or multithread code, do less dispatching for critical parts of the code, less context switching makes it a lot more efficient

[elizarov]

@thana Can you provide a self-contained benchmark that demonstrates your problem? So far, our experience was quite positive in figure out how to optimize when we were benchmarking our code.

[thana]

@elizarov most probably i'm just confused by the code, the compiler generates in regard with coroutines. so in the end it might be a problem one gets used with.
so i think i am hoping for answers like "yes that's confusing but if you put a filter on methods X and Y everything gets much cleaner" or something similar 😉

[elizarov]

If you can share the code, I'm sure we'll be able to come with an advise on how to improve it. So far your topic-starter question is non-actionable.

[thana]

im afraid the actual code doesnt exist any more. in our case we were iterating a Sequence and doing some havy stuff on the items. The profiler revealed there was a huhge amount of time spent in invokeSuspend and we were struggeling wether it was really a problem in the Sequence itself or just coincidence

[elizarov]

What kind of profiler you were using?

[thana]

jprofiler's cpu profiler

[elizarov]

It is highly likely that it was just a coincidence (google for "safepoint bias")

[thana]

thank you!