https://kotlinlang.org logo
Join Slack
Powered by
Has anyone looked at / benchmarked the GC overhead...
# coroutines
r
Has anyone looked at / benchmarked the GC overhead of coroutine suspend and resume?
o
GC overhead?
r
Yeah. Not sure what's unclear about that.
Assuming a JVM backend...
o
I'm just curious where you think it would come from
I don't think it has a significant impact on GC, as all the fields are contained in a single object so it doesn't create any sort of loop unless you already had one
r
The Continuation object that represents the continuation has to be GCed after use. Is that the single object you refer to?
o
yes
but that is not related to suspend/resume, it's not reallocated on resume -- it's only created on the call, and made GC'able after the call finishes
r
Ok, so is "garbage created by suspend functions" better wording?
o
yes
r
A 
Continuation
is an interface so without digging into the implemenation details its hard to say how big its reference tree can get. That's why I'm asking...
o
it's as big as the variables in your coroutine
it's unique for each 
suspend
function (see generated bytecode)
r
+ whatever is in the CoroutineContext
o
yes, though I would consider that a "variable in your coroutine"
r
Yeah, but I mean, there is additional memory in the CoroutineContext that are not variables in my coroutine. For example, the job and coroutine name and etc. etc.
o
yes
r
So coming full circle... I don't know exactly what all that additional stuff is without digging deep so... what is the GC overhead of all that stuff?
o
I'd say it's hard to measure
I suppose the best thing to do might be running a bunch of coroutines and seeing what happens to allocations, I personally have not done that
r
Me either... hence the question 🙂
o
personally I think it's so variable, but also so tiny, that you'd just have to measure your own application
there's certainly some overhead, but I don't think it's very significant, from a small test I did with millions of `delay`ing coroutines
r
Yeah I'll probably throw a JMH benchmark together...
l
Please share results when you do
3 Views
Open in Slack
PreviousNext
Powered by