Closed Bug 1647264 Opened 4 years ago Closed 2 years ago

2.36 - 4.85% tart (macosx1014-64-shippable) regression on push 55b1d1bb86590008331fe0d4f98c3ff7fd1322d1 (Tue June 16 2020)

Categories

(Core :: Web Painting, defect, P3)

defect

Tracking

()

RESOLVED WONTFIX
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.

Flags: needinfo?(mstange.moz)
Component: Performance → Web Painting
Product: Testing → Core

Set release status flags based on info from the regressing bug 1592739

Confirmed that this regression rode to Beta with the 79 uplift yesterday.

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.

Assignee: nobody → mstange.moz
Status: NEW → ASSIGNED
Flags: needinfo?(mstange.moz)

Markus, did you manage to get those perf numbers?

Flags: needinfo?(mstange.moz)

I'm kicking off the try pushes now.

Flags: needinfo?(mstange.moz)

Try pushes are in progress. I'll update this bug once I have numbers.

Before bug 1592739 and bug 1592016 After bug 1592739 and bug 1592016
WR off 3.70 (try push) 3.86 (try push)
WR on 6.41 (try push) 4.57 (try push)

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.

I'm going to call this wontfix for 80 at this point.

Target Milestone: mozilla79 → ---
Priority: -- → P3
Has Regression Range: --- → yes
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.