O
OneJS3y ago
Singtaa

Can you send me an example code

Can you send me an example code?
26 Replies
Unknown User
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
Singtaa
SingtaaOP3y ago
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
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
Singtaa
SingtaaOP3y ago
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
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
Singtaa
SingtaaOP3y ago
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 allocation
Unknown User
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
Singtaa
SingtaaOP3y ago
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?:
const Clock = () => {
const ref = useRef<Dom>()
const [timeStr, setTimeStr] = useState(new Date().toTimeString())

let updateTime = () => {
data.time = new Date().getSeconds();
ref.current.ve[0].text = JL.apply(logic, data)
setTimeout(updateTime, 10)
}
setTimeout(updateTime, 10)

return <div ref={ref}>{timeStr}</div>
}
const Clock = () => {
const ref = useRef<Dom>()
const [timeStr, setTimeStr] = useState(new Date().toTimeString())

let updateTime = () => {
data.time = new Date().getSeconds();
ref.current.ve[0].text = JL.apply(logic, data)
setTimeout(updateTime, 10)
}
setTimeout(updateTime, 10)

return <div ref={ref}>{timeStr}</div>
}
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
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
Singtaa
SingtaaOP3y ago
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
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
Singtaa
SingtaaOP3y ago
Yeah I was testing without the coroutine stuff (directly from the update loop). I will have the new implementation checked in tomorrow
Unknown User
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
Singtaa
SingtaaOP3y ago
I still don't know why Coroutine + Jint Interop introduces such GC issues. But removing them (Coroutines) seemed to make everything normal.
Unknown User
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
Singtaa
SingtaaOP3y ago
It's a big issue. I'm really glad you spot it out!
Unknown User
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
Singtaa
SingtaaOP3y ago
It was really frustrating debugging those Coroutines too, so I don't miss them heh
Unknown User
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
Singtaa
SingtaaOP3y ago
Yup, I'll check it out
Unknown User
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
Singtaa
SingtaaOP3y ago
Good luck on the DrawIO project. It'll be a good test of the Vector API Haha for sure
Unknown User
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
Singtaa
SingtaaOP3y ago
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:
const Clock = () => {
const ref = useRef<Dom>()
const [timeStr, setTimeStr] = useState(new Date().toTimeString())

useEffect(() => {
setInterval(() => {
var d = new Date()
data.time = d.getSeconds()
setTimeStr(d.toLocaleTimeString() + " modulo:" + JL.apply(logic, data))
}, 1000)
}, [])

return <div ref={ref}>{timeStr}</div>
}
const Clock = () => {
const ref = useRef<Dom>()
const [timeStr, setTimeStr] = useState(new Date().toTimeString())

useEffect(() => {
setInterval(() => {
var d = new Date()
data.time = d.getSeconds()
setTimeStr(d.toLocaleTimeString() + " modulo:" + JL.apply(logic, data))
}, 1000)
}, [])

return <div ref={ref}>{timeStr}</div>
}
otherwise setInterval will run everytime the comp get re-rendered due to state change. Just checked in the coroutine-less implementations!
Unknown User
Unknown User3y ago
Message Not Public
Sign In & Join Server To View
Singtaa
SingtaaOP3y ago
nah my mistake
Want results from more Discord servers?
Add your server