Closed Bug 1127608 Opened 10 years ago Closed 6 years ago

Always schedule 10ms GC slices to improve animating experience

Categories

(Core :: JavaScript: GC, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID
flash10

People

(Reporter: terrence, Unassigned)

References

(Blocks 1 open bug)

Details

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
Summary: Always schedule 10ms GC slices → Always schedule 10ms GC slices to improve animating experience
Is this still relevant? have the annimating herustics improved?
Whiteboard: [qf]
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
Whiteboard: [qf]
You need to log in before you can comment on or make changes to this bug.