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)
Core
JavaScript: GC
Tracking
()
NEW
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.
Comment 1•7 years 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.
Comment 2•7 years ago
|
||
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).
Updated•7 years ago
|
status-firefox57:
--- → affected
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•