Closed Bug 1690494 Opened 4 years ago Closed 4 years ago

2.22 - 28.74% facebook / facebook / office / wikipedia / yandex / youtube (linux64-shippable, linux64-shippable-qr) regression on push d9e5a018312eccf63acbda32759d90e2f92175d7 (Sat January 30 2021)

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox85 --- unaffected
firefox86 --- unaffected
firefox87 --- affected

People

(Reporter: Bebe, Unassigned)

References

(Regression)

Details

(Keywords: perf, perf-alert, regression)

Perfherder has detected a browsertime performance regression from push d9e5a018312eccf63acbda32759d90e2f92175d7. As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

Ratio Suite Test Platform Options Absolute values (old vs new)
29% facebook LastVisualChange linux64-shippable cold nocondprof 1,426.67 -> 1,836.67
21% facebook LastVisualChange linux64-shippable-qr cold nocondprof webrender 1,530.00 -> 1,850.00
21% facebook LastVisualChange linux64-shippable-qr cold nocondprof webrender 1,533.33 -> 1,850.00
5% facebook ContentfulSpeedIndex linux64-shippable cold nocondprof 1,086.00 -> 1,142.83
4% office ContentfulSpeedIndex linux64-shippable-qr cold nocondprof webrender 1,550.58 -> 1,616.75
4% yandex ContentfulSpeedIndex linux64-shippable nocondprof warm 81.50 -> 84.92
4% office ContentfulSpeedIndex linux64-shippable-qr nocondprof warm webrender 891.33 -> 923.08
3% wikipedia loadtime linux64-shippable nocondprof warm 770.56 -> 790.96
2% youtube ContentfulSpeedIndex linux64-shippable-qr nocondprof warm webrender 812.58 -> 832.83
2% wikipedia loadtime linux64-shippable-qr nocondprof warm webrender 794.29 -> 811.96

Improvements:

Ratio Suite Test Platform Options Absolute values (old vs new)
5% google-slides PerceptualSpeedIndex linux64-shippable nocondprof warm 547.79 -> 520.08
4% amazon SpeedIndex linux64-shippable-qr cold nocondprof webrender 916.50 -> 880.42
4% google-slides PerceptualSpeedIndex linux64-shippable cold nocondprof 906.83 -> 872.58
2% google-docs SpeedIndex linux64-shippable nocondprof warm 1,143.08 -> 1,116.33
2% linkedin SpeedIndex linux64-shippable-qr nocondprof warm webrender 1,130.67 -> 1,106.25

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?(emilio)

I only see Facebook and GDocs jobs in here. I think I triggered profiles for them but if you could double-check I did that correctly that'd be great.

Keeping my ni? to check back the profiles.

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

status-firefox85: --- → unaffected
status-firefox86: --- → unaffected
status-firefox-esr78: --- → unaffected

So I'm confused because there's only a tiny bit of code filtering by nsNativeBasicTheme in the profile on Facebook, which is just the scrollbar thumb painting...

I'll check if some of the native-theme-only CSS code causes this but otherwise I'm kinda out of ideas.

I'm comparing this profile ("good") with this one ("bad"), and not getting very far.

The only concerning thing I see is that in some of the "bad" videos, there's an horizontal scrollbar for a small amount of time. Other than that they seem fairly comparable. I'll try to reproduce that and dig.

Do you know what the window/viewport size is for these tests on automation, so that I can try to reproduce that scrollbar issue?

Flags: needinfo?(gmierz2)

From a bit of playing with the page, I think it's 1024 pixels wide.

Bingo, so this is only about scrollbar size, see this comparison. The scrollbars in ubuntu 16 are 10px. The scrollbars in the new theme are 12px and for that test-case in particular they are too big.

We could fix this by making the scrollbar smaller I guess, but not sure it's worth it.

I think this is wontfix as per the above, but feel free to reopen if you disagree. This shouldn't affect performance for most users (default GTK scrollbars are 12px since long ago, and I expect most users to use windows different to 1024px).

Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(emilio)
Resolution: --- → WONTFIX

Thanks for digging into this :emilio, I agree it's a wontfix.

Flags: needinfo?(gmierz2)
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.