26 Replies
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Thanks!
Found the bug and fixed in the latest commit
The
setTimeout
cache wasn't properly cleared after each function call (now it is)Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I think I first tried removing
JL.apply
, and then the memory would still go up a little. And the timing of the increase was every 1-2 seconds, so it was definitely related to setTimeout
Worst case scenario would be some memory leak in Jint (fortunately not the case)Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
It'll depend on what you do really. GC will always be there for Managed code. In general, even if you allocate big strings every frame, the GC spike won't be too bad. Incremental GC and Release build help in some cases. Are you seeing spikes that are noticeably affecting your framerate?
On OneJS's side I'll replace the coroutine usage for
setTimeout
et al in the near future to lessen the GC allocationUnknown User•3y ago
Message Not Public
Sign In & Join Server To View
Spent the last few hours looking into this. Originally I didn't observe any major GC spikes out of the ordinary. But then as I let the timer run for a few minutes, the spikes did get worse and worse (continuously).
The biggest contributing factor was JsonLogic.apply (the recursion in it). This leads me to think there may be some interop issue with Jint.
Weirdest part is that memory usage isn't really increasing
Okay I think there are 2 separate issues. One is the GC.Collect spike which on my machine peaks at ~8ms. Another is with the
setState
call that continuously gets worse performance over time for some reason.
@Sciumo What's your GC spike like when you use the following Clock
instead?:
Okay If I directly call setState
from the Update loop, the perf is perfect (no degradation). So there may be something going on with the coroutines. I'll replace the coroutine usage over the weekend.Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Yeah I was mostly observing it in Build (with 2022.2b1)
Incremental GC turned off, Editormode,
JSONLogic.apply
everyframe, gives me 60ms GC.Collect
spike.
Incremental GC turned off, Standalone Build, JSONLogic.apply
everyframe, gives me 8ms GC.Collect
spike.
Incremental GC turned on, Standalone Build, JSONLogic.apply
everyframe, gives me <2ms GC.Collect
spike.Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Yeah I was testing without the coroutine stuff (directly from the update loop). I will have the new implementation checked in tomorrow
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I still don't know why Coroutine + Jint Interop introduces such GC issues. But removing them (Coroutines) seemed to make everything normal.
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
It's a big issue. I'm really glad you spot it out!
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
It was really frustrating debugging those Coroutines too, so I don't miss them heh
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Yup, I'll check it out
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Good luck on the DrawIO project. It'll be a good test of the Vector API
Haha for sure
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I think I tunnel-visioned on the GC issue that I forgot you can't just put setTimeout + setState in the Comp's main body. You need to wrap them in a side effect:
otherwise
setInterval
will run everytime the comp get re-rendered due to state change.
Just checked in the coroutine-less implementations!Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
nah my mistake