Async substeps on Speedometer 3 often measure two paints instead of one
Categories
(Core :: Performance Engineering, task)
Tracking
()
People
(Reporter: mstange, Unassigned)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [sp3])
Most "async" substeps of the TodoMVC subtests of Speedometer 3 appear to measure two paints rather than just one. This seems counter to the test's intentions and affects our score negatively.
Here's a profile of one TodoMVC-React-Complex-DOM.CompletingAllItems-async substep: https://share.firefox.dev/45YQL94
At the beginning, it contains the style + layout flush + paint of the current refresh tick. This is what we want to measure.
But then it also contains the following: another refresh tick (including nsRefreshDriver::DispatchAnimationEvents and a paint), a message event, and an idle GC task (whose idle timeout has been reached).
This extra work is not something we want to measure.
It's no wonder our paint times look high on TodoMVC-React-Complex-DOM: We're measuring two paints when other browsers are probably only measuring one paint.
To some degree, this problem could be prevented by the speedometer harness: When it calls setTimeout(..., 0), it could also call requestAnimationFrame, and then stop the async substep's measurement at whichever thing happens first. This would avoid measuring the second paint, the message event, and the GC. But it would not reliably avoid measuring the nsRefreshDriver::DispatchAnimationEvents work, because animation events are dispatched before requestAnimationFrame callbacks are called.
It looks like the "double tick" issue affects all TodoMVC subtests, except the ones that are fast enough to fit their sync+async work inside a single vsync interval. So, depending on vsync rate and machine + test performance, there's a cliff where you go from measuring one paint to measuring two paints.
If we want to do something about this by changing Firefox's behavior, maybe we could give preferential treatment to 0-interval timeouts which were enqueued inside a rAF callback (but preserving ordering somehow).
|
||
Updated•2 years ago
|
The point is that it measures all the task triggered by the test before that setTimeout(0) runs. If we trigger paints too eagerly, we should fix that.
I've been investigating this.
|
Reporter | |
Comment 3•2 years ago
|
||
Was this fixed by bug 1857618 or is there more work to do?
There might be still some tweaks, but perhaps we can close this and then file new bugs when needed.
Description
•