Talos has detected a Firefox performance regression from push: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=c5feed1e4a18a5ef594c9385927795109b750abf As author of one of the patches included in that push, we need your help to address this regression. Regressions: 7% tps linux64 pgo e10s stylo 10.04 -> 10.70 5% tps linux64 opt e10s stylo 11.16 -> 11.77 You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=14768 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

And here are the Gecko profiles for tps, on Linux 64: before: https://perf-html.io/from-url/https%3A%2F%2Fqueue.taskcluster.net%2Fv1%2Ftask%2FcXFDggRZQfK-c60kgbBV5g%2Fruns%2F0%2Fartifacts%2Fpublic%2Ftest_info%2Fprofile_tps.zip after: https://perf-html.io/from-url/https%3A%2F%2Fqueue.taskcluster.net%2Fv1%2Ftask%2FA-r1St09TTiNhXaQPqelvQ%2Fruns%2F0%2Fartifacts%2Fpublic%2Ftest_info%2Fprofile_tps.zip

I noticed in the profile provided in comment 1 that before the patch from bug 1260036, there's a long restyle that happens earlier. With the patch applied, it happens during the refresh driver tick. And this long restyle is caused by an invalidation done in moveTabTo. This matches pretty well the changes I did in bug 1260036 where I postponed the sync style flush using requestAnimationFrame. Looking at the code of the Talos test, there's a gBrowser.moveTabTo call right before we start measuring: https://searchfox.org/mozilla-central/rev/3fdc491e118c5cdfbaf6e2d52f3466d2b27ad1de/testing/talos/talos/tests/tabswitch/api.js#241 That used to be sync, now its action happens at the next refresh driver tick, so we end up including this slow restyle in the tps measurement. Then the test fix is easy, we just need to wait for the tab move to finish before we start the measurement. I'm attaching the straightforward patch to do that, and try confirms this fixes the reported regression: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=ae62f0cd8fd753d1ba1f2a78e12589f55e4fde37&newProject=try&newRevision=60e25b0bd17695a843b407f9b9931f24e153cfbd&framework=1&showOnlyImportant=1

Comment on attachment 8998129 [details] [diff] [review] Fix tps Review of attachment 8998129 [details] [diff] [review]: ----------------------------------------------------------------- Thanks!

Pushed by archaeopteryx@coole-files.de: https://hg.mozilla.org/integration/mozilla-inbound/rev/e9b7afb7ae54 The tps (tab switch) talos test should wait until we are done moving tabs before starting its measurement, r=mconley

I confirm issue was fixed: == Change summary for alert #14829 (as of Wed, 08 Aug 2018 14:11:13 GMT) == Improvements: 7% tps linux64-qr opt e10s stylo 9.96 -> 9.24 7% tps linux64 pgo e10s stylo 10.53 -> 9.77 6% tps linux64 opt e10s stylo 11.68 -> 10.96 For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=14829