2.36 - 4.85% tart (macosx1014-64-shippable) regression on push 55b1d1bb86590008331fe0d4f98c3ff7fd1322d1 (Tue June 16 2020)
Categories
(Core :: Web Painting, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox77 | --- | unaffected |
firefox78 | --- | unaffected |
firefox79 | + | wontfix |
firefox80 | + | wontfix |
firefox81 | - | wontfix |
firefox82 | - | wontfix |
People
(Reporter: alexandrui, Assigned: mstange)
References
(Regression)
Details
(4 keywords)
Perfherder has detected a talos performance regression from push 55b1d1bb86590008331fe0d4f98c3ff7fd1322d1. As author of one of the patches included in that push, we need your help to address this regression.
Regressions:
5% tart macosx1014-64-shippable opt e10s stylo 3.69 -> 3.87
2% tart macosx1014-64-shippable opt e10s stylo 3.79 -> 3.88
Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the offending patch(es) will be backed out in accordance with our regression policy.
For more information on performance sheriffing please see our FAQ.
Reporter | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Set release status flags based on info from the regressing bug 1592739
Comment 2•4 years ago
|
||
Confirmed that this regression rode to Beta with the 79 uplift yesterday.
Assignee | ||
Comment 3•4 years ago
|
||
I haven't tracked down the cause of this regression yet. My expectation is that it has to do with layer transparency, which was changed in bug 1592739; now more parts of the browser chrome are transparent. This might have increased costs from clearing layers during painting and from composition.
However, bug 1592739 was a necessary piece to get WebRender ready for shipping, and WebRender is supposed to improve performance. This regression affects non-WebRender.
My plan is to get performance numbers with WebRender on, and then see if those are better than the non-WebRender numbers. If they are, I think we can justify a temporary non-WebRender regression and not spend more time investigating this bug.
Comment 4•4 years ago
|
||
Markus, did you manage to get those perf numbers?
Assignee | ||
Comment 6•4 years ago
|
||
Assignee | ||
Comment 7•4 years ago
|
||
I got the numbers. It turns out WebRender is doing quite a bit worse on this test than non-WebRender. However, it was doing way worse before bug 1592739 and bug 1592016.
I will try to find out how to make the WebRender configuration faster. However, I don't think I'll be able to fix it for 79, so I think we should wontfix this bug for 79.
The non-WebRender regression isn't all that big. This is a very sensitive test, designed to catch small regressions under the frame budget. The numbers are milliseconds, and as long as they're below 16ms, the animation stays within the 60fps frame budget. So even with the regression the tab animations are still perfectly smooth.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 8•4 years ago
|
||
I'm going to call this wontfix for 80 at this point.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•2 years ago
|
Description
•