4.27 - 7.86% sessionrestore / sessionrestore_no_auto_restore / tart (linux64) regression on push cb3ca443d8c3f635764d2cc77f42aff6c3daecda (Thu Jan 17 2019)
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: igoldan, Unassigned)
References
Details
(Keywords: perf, regression, talos-regression)
Talos has detected a Firefox performance regression from push:
As author of one of the patches included in that push, we need your help to address this regression.
Regressions:
8% sessionrestore_no_auto_restore linux64 opt e10s stylo 329.92 -> 355.83
7% sessionrestore linux64 pgo e10s stylo 288.79 -> 310.33
7% sessionrestore linux64 opt e10s stylo 314.33 -> 336.08
6% tart linux64 pgo e10s stylo 1.56 -> 1.66
5% sessionrestore_no_auto_restore linux64 pgo e10s stylo 307.58 -> 323.08
4% tart linux64 opt e10s stylo 1.68 -> 1.75
You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=18776
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/Performance_sheriffing/Talos/Tests
For information on reproducing and debugging the regression, either on try or locally, see: https://wiki.mozilla.org/Performance_sheriffing/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/Performance_sheriffing/Talos/RegressionBugsHandling
|
Reporter | |
Updated•6 years ago
|
|
|
Reporter | |
Updated•6 years ago
|
|
|
Reporter | |
Comment 1•6 years ago
|
||
Here are the Gecko profiles for sessionrestore on Linux 64bit PGO:
for sessionrestore_no_auto_restore on Linux 64bit PGO:
for tart on Linux 64bit PGO:
|
||
Comment 2•6 years ago
|
||
I think it's expected. When system titlebar is disabled and Firefox draw the titlebar, we need to load titlebar button icons at start:
We had this performance regression before and that was fixed by deferred icons loading performed when user disables the system titlebar. But when the titlebar is disabled by default we need to load the icons at start.
|
|
||
Updated•6 years ago
|
|
|
||
Comment 3•6 years ago
|
||
Bug 1489499 is the original regression which was fixed by deferred icons loading.
|
|
Reporter | |
Comment 4•6 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #2)
I think it's expected. When system titlebar is disabled and Firefox draw the titlebar, we need to load titlebar button icons at start:
We had this performance regression before and that was fixed by deferred icons loading performed when user disables the system titlebar. But when the titlebar is disabled by default we need to load the icons at start.
So... Should we close this this as wontfix?
|
|
||
Comment 5•6 years ago
|
||
(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #4)
(In reply to Martin Stránský [:stransky] from comment #2)
I think it's expected. When system titlebar is disabled and Firefox draw the titlebar, we need to load titlebar button icons at start:
We had this performance regression before and that was fixed by deferred icons loading performed when user disables the system titlebar. But when the titlebar is disabled by default we need to load the icons at start.
So... Should we close this this as wontfix?
Yes, as it comes from the new feature.
|
||
Comment 6•6 years ago
|
||
That's a large regression from just loading icons, though...
|
|
||
Comment 7•6 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #6)
That's a large regression from just loading icons, though...
The affected code is CreateHeaderBarButtons() routine from widget/gtk/WidgetStyleCache.cpp.
Description
•