Closed Bug 1489499 Opened 6 years ago Closed 6 years ago

2.47 - 5.58% ts_paint / ts_paint_webext (linux64, linux64-qr) regression on push 6615b44439f9ae068611efca66cb09bb94cd3920 (Thu Sep 6 2018)

Categories

(Core :: Widget: Gtk, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla64
Tracking Status
firefox-esr60 --- unaffected
firefox62 --- unaffected
firefox63 --- unaffected
firefox64 --- fixed

People

(Reporter: jmaher, Assigned: stransky)

References

Details

(Keywords: perf, regression, talos-regression)

Attachments

(1 file)

Talos has detected a Firefox performance regression from push:

https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=6615b44439f9ae068611efca66cb09bb94cd3920

As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

  6%  ts_paint_webext linux64 pgo e10s stylo        197.79 -> 208.83
  6%  ts_paint linux64 opt e10s stylo               196.62 -> 207.50
  4%  ts_paint_webext linux64 opt e10s stylo        199.75 -> 207.50
  4%  ts_paint linux64 opt e10s stylo               199.88 -> 207.25
  3%  ts_paint_webext linux64-qr opt e10s stylo     267.58 -> 275.67
  2%  ts_paint linux64-qr opt e10s stylo            267.22 -> 273.83


You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=15702

On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a treeherder page showing the Talos jobs in a pushlog format.

To learn more about the regressing test(s), please see: https://wiki.mozilla.org/Buildbot/Talos/Tests

For information on reproducing and debugging the regression, either on try or locally, see: https://wiki.mozilla.org/Buildbot/Talos/Running

*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***

Our wiki page outlines the common responses and expectations: https://wiki.mozilla.org/Buildbot/Talos/RegressionBugsHandling
:stransky, I see that you authored the patches in bug 1408360, these have resulted in a regression in our browser startup time.  Can you take a look at this and determine if we need to backout, fix the regression in part or whole, or accept it?
Component: General → Widget: Gtk
Flags: needinfo?(stransky)
Product: Testing → Core
in addition AWSY found some memory regressions:
== Change summary for alert #15707 (as of Fri, 07 Sep 2018 18:31:03 GMT) ==

Regressions:

  4%  Base Content Heap Unclassified linux64-qr opt stylo     5,289,615.33 -> 5,480,785.00
  3%  Base Content Heap Unclassified linux64 opt stylo        5,292,887.67 -> 5,476,161.00

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=15707
Yes, I'll look at it.
Assignee: nobody → stransky
Flags: needinfo?(stransky)
Yes, I see the regression, there's a backtrace:

#0  0x00007fffe3e1f297 in CreateHeaderBar() () at /home/komat/tmp676-trunk-gtk3/src2/widget/gtk/WidgetStyleCache.cpp:764
#1  0x00007fffe3e1f4c7 in CreateWidget(WidgetNodeType) (aWidgetType=MOZ_GTK_HEADER_BAR)
    at /home/komat/tmp676-trunk-gtk3/src2/widget/gtk/WidgetStyleCache.cpp:866
#2  0x00007fffe3e1f520 in GetWidget(WidgetNodeType) (aWidgetType=MOZ_GTK_HEADER_BAR)
    at /home/komat/tmp676-trunk-gtk3/src2/widget/gtk/WidgetStyleCache.cpp:879
#3  0x00007fffe3e263e2 in GetGtkHeaderBarButtonLayout(WidgetNodeType*, int) (aButtonLayout=0x7fffffffb1d0, aMaxButtonNums=3)
    at /home/komat/tmp676-trunk-gtk3/src2/widget/gtk/gtk3drawing.cpp:439
#4  0x00007fffe3e48052 in nsLookAndFeel::EnsureInit() (this=0x7ffff6a5fe00)
    at /home/komat/tmp676-trunk-gtk3/src2/widget/gtk/nsLookAndFeel.cpp:1169

The CreateHeaderBar() is called even when titlebar rendering is disabled. I'll try optimize that initialization better.
We don't set gtk_header_bar_set_decoration_layout() so we don't need to query the layout
by gtk_header_bar_get_decoration_layout(). That means we don't need to create the GtkHeaderBar
at startup when titlebar rendering is disabled.

Also unify window/header bar construction at CreateHeaderBarWidget() and assert when the widgets
are already created.
Comment on attachment 9007753 [details]
Bug 1489499 - Don't call gtk_header_bar_get_decoration_layout() to get titlebar layout, r=jhorak

Jan Horak [:jhorak] has approved the revision.
Attachment #9007753 - Flags: review+
Pushed by csabou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e3ba99143d2f
Don't call gtk_header_bar_get_decoration_layout() to get titlebar layout, r=jhorak
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/e3ba99143d2f
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
and we have improvements:
== Change summary for alert #15807 (as of Tue, 11 Sep 2018 13:50:42 GMT) ==

Improvements:

  7%  ts_paint linux64 pgo e10s stylo            211.04 -> 197.33
  4%  ts_paint_webext linux64 opt e10s stylo     209.42 -> 200.83
  4%  ts_paint linux64 opt e10s stylo            208.50 -> 200.50
  3%  ts_paint linux64-qr opt e10s stylo         276.67 -> 267.42

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=15807
and the awsy metrics:
== Change summary for alert #15797 (as of Tue, 11 Sep 2018 13:50:42 GMT) ==

Improvements:

  4%  Base Content Heap Unclassified linux64 opt stylo        5,472,912.33 -> 5,275,645.67
  4%  Base Content Heap Unclassified linux64-qr opt stylo     5,468,264.33 -> 5,272,649.33
  2%  Base Content Explicit linux64-qr opt stylo              14,292,480.00 -> 13,997,226.67
  2%  Base Content Explicit linux64 opt stylo                 14,251,593.14 -> 13,961,728.00

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=15797
See Also: → 1521039
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: