OneJS•3y ago

Can you send me an example code

Can you send me an example code?

26 Replies

Unknown User•3y ago

Message Not Public

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

Singtaa•3y 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•3y ago

Message Not Public

Singtaa•3y 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•3y ago

Message Not Public

Singtaa•3y 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•3y ago

Message Not Public

Singtaa•3y 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•3y ago

Message Not Public

Singtaa•3y 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•3y ago

Message Not Public

Singtaa•3y 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•3y ago

Message Not Public

Gaming

Programming

Can you send me an example code