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?

gecko profiles of ts_paint- before: https://perf-html.io/from-url/https%3A%2F%2Fqueue.taskcluster.net%2Fv1%2Ftask%2FLwyh8tooRbKKClRVBrioGQ%2Fruns%2F0%2Fartifacts%2Fpublic%2Ftest_info%2Fprofile_ts_paint.zip after: https://perf-html.io/from-url/https%3A%2F%2Fqueue.taskcluster.net%2Fv1%2Ftask%2FCmBWvS50RxaescCpcSCOJA%2Fruns%2F0%2Fartifacts%2Fpublic%2Ftest_info%2Fprofile_ts_paint.zip from these links: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&searchStr=linux,talos,other,o-p&tochange=6615b44439f9ae068611efca66cb09bb94cd3920&fromchange=61970ba394500a42b1602ba7717574fcecc01ea1&selectedJob=198057351

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.

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.

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

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