Open Bug 1373292 Opened 7 years ago Updated 2 years ago

Fix GC_MMU_50 telemetry metric to accommodate idle time

Categories

(Core :: JavaScript: GC, enhancement, P3)

enhancement

Tracking

()

Tracking Status
firefox57 --- affected

People

(Reporter: sfink, Unassigned)

References

Details

As seen in http://alerts.telemetry.mozilla.org/index.html#/detectors/1/metrics/575/alerts/?from=2017-06-11&to=2017-06-11 our GC_MMU_50 percentages have tanked. I think this is because we now have 50ms idle slices that create a region of MMU50=0%, surrounded by MMU50=very small as you get a little more mutator time mixing in, producing the smooth curve dropping down from the 0 point.

I don't have an explanation for why the rightmost peak (MMU50=78%) got lopped off, though.

I believe it would be more accurate to exclude any time spent in an idle GC entirely.
Related, bug 1373185.

What's important from the user perspective is that if they type something during a GC or CC, or the site has a pending update, that the browser responds to it. So we want to measure and minimize the amount of time a GC or CC slice delays that action.
50ms delay is per user interaction research thought to be ok for input, which is why requestIdleCallback spec defaults to 50ms as the max value of idle period. There is no need to try to minimize GC/CC slices, but ensure that they don't disturb non-idle time (since that is when user input and painting and such happens).
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.