Closed gfeun closed 4 years ago
Sounds like a good direction and possibly another quick win. Have you tried changing the demo code to use this method?
Yes I'm on it. I'm slow since i don't know typescript but I should have some results today
Excellent. I'd love to see how it affects the performance on Firefox
I think I identified a potential performance bottleneck due to the way task queing works in JS event loop
Disclaimer, I'm not familiar with JS internals, just compiling some search results
This setTimeout(fn, 0) is potentially "rate limited" by browsers : https://github.com/wokwi/avr8js/blob/3b7a122e9ca5252ea20376ce436809ef85602120/demo/src/execute.ts#L50
From https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout
While it states that this applies to "recursive" setTimeout calls, it is not clear to me if it applies to consecutive setTimeout calls. It may explain performance differences between Chrome and Firefox because they may handle this differently.
The "recommended" workaround I found is to use the window.postMessage API to schedule next tasks.
This old posts (maybe not relevant anymore) details the throttling happening: https://dbaron.org/log/20100309-faster-timeouts
And the associated test page gives me better performances for the postMessage (setZeroTimeout) method (https://dbaron.org/mozilla/zero-timeout)
This SO answer: https://stackoverflow.com/questions/18826570/settimeout0-vs-window-postmessage-vs-messageport-postmessage with a corresponding jsfiddle http://jsfiddle.net/Noseratio/wPCN4/6/ points in the same direction