Closed Bug 1465951 Opened 6 years ago Closed 6 years ago

6.88% tps (linux64-qr) regression on push fe8aa70475dde011b190f1c5c7df5e56814b1cde (Tue May 29 2018)

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jmaher, Unassigned)

References

Details

(Keywords: perf, regression, talos-regression)

Talos has detected a Firefox performance regression from push:

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

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

Regressions:

  7%  tps linux64-qr opt e10s stylo     11.12 -> 11.88

Improvements:

  4%  tps windows10-64-qr opt e10s stylo     12.04 -> 11.54


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

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
Component: General → Tabbed Browser
Product: Testing → Firefox
this is a noisy test which happens to shift slight on both -qr builds when this push happened:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9e1a3230d085fb9c158a08b25227178f42ec823f&tochange=f9188b8db69db195ae4ae94b4ce895cc56d3990f

the push is disabling tab layer cache- is that a backout?  I couldn't see corresponding tps changes in the last month to indicate that enabling tab layer cache was doing the reverse here.

:dthayer, can you take a look at this and determine if we should back out the patch, if we can reduce/fix the regression, or if we need to live with it.
Flags: needinfo?(dothayer)
https://treeherder.mozilla.org/perf.html#/graphs?series=mozilla-inbound,1686036,1,1&series=autoland,1685771,1,1

It very much looks like turning on the tab layer cache made tps go all noisy, and then the disabling of the tab layer cache brought it back down. That being said, we haven't spent much time looking at the actual performance of talos tests on QR yet, so it's possible that we're still doing something dumb on the webrender/platform side that is getting tickled by the tab layer cache.
This is effectively a backout, yes. Could you explain why you don't see the dip around May 22nd as the tab layer cache doing the reverse? Visually it looks mirrored to me - the post-patch numbers look a tiny bit higher, but I can't really judge if that looks like normal noise or not.
Flags: needinfo?(dothayer)
ok, for the win10-qr case it is very clear; for the linux64-qr case, I can see a bit of a difference, it is just slightly more pronounced now- I agree this is just a reverse and we should just close it out.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.