In order to improve throughput when not animating, we schedule 40ms slices instead of the typical 10ms slices. The thinking is that if an idle page responds within 50ms to a user input, it will still feel responsive. Unfortunately, our "not animating" heuristics are not that great and we currently miss important things like scrolling the page. We could fix this one case, however, since the results of getting this heuristic wrong are so awful, we should probably just use 10ms slices at all times and accept that we'll have less throughput sometimes.

scrolling a page should trigger refresh driver to run, and we use that to tell GC that shorter slices should be used. But anyhow, if we can use always 10ms slices, that makes the behavior more predictable and simplifies the code, so I'm all for it. We could also reduce the 40ms to something shorter, like 16ms + the shorter slice, so currently 26ms. (and it might make sense to try to reduce the 10ms slice. In CC we got pretty good results when the slice went from 10ms to 5ms.)

The danger with using javascript.options.mem.gc_incremental_slice_ms slices everywhere* is that it could push us over the edge of triggering a full GC more often, right? But I wonder how common it is for us to *not* be painting at all, yet allocating enough to fall behind. I could imagine some potential scenarios, like a long-running browser-based simulation where only the final result matters (which would hopefully trigger per-zone collections!), but I would imagine most heavy allocation scenarios to have some sort of visual impact. * javascript.options.mem.gc_dynamic_mark_slice doubling aside

Is this still relevant? have the annimating herustics improved?

We use mostly idle times for scheduling, and when idle, max slice is 50ms. If GC slice is run when we aren't idle, slice time is 5ms. Idleness means no refresh driver ticking (no animations etc) nor other higher priority stuff on the main event loop.