Fix GC_MMU_50 telemetry metric to accommodate idle time

NEW
Unassigned

Status

()

Core
JavaScript: GC
P3
normal
a year ago
9 months ago

People

(Reporter: sfink, Unassigned)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(firefox57 affected)

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.

Comment 1

a year ago
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).
status-firefox57: --- → affected
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.