Talos has detected a Firefox performance regression from push:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=87ad4b91e29fb9025d90ceb89a62b5a4eb7d584a

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

Regressions:

2% sessionrestore linux64-qr opt e10s stylo 789.54 -> 802.83
2% ts_paint_webext linux64-qr opt e10s stylo 849.79 -> 862.50

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

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

Gecko profiles:

Before:
https://perf-html.io/from-url/https%3A%2F%2Fqueue.taskcluster.net%2Fv1%2Ftask%2FAmR7zOrjSXaLmXdecLxTNQ%2Fruns%2F0%2Fartifacts%2Fpublic%2Ftest_info%2Fprofile_ts_paint_webext.zip

After:
https://perf-html.io/from-url/https%3A%2F%2Fqueue.taskcluster.net%2Fv1%2Ftask%2FPd7C0XbKRAqr_Hhd1LwiDQ%2Fruns%2F0%2Fartifacts%2Fpublic%2Ftest_info%2Fprofile_ts_paint_webext.zip

This is a pretty surprising regression given the code changes...

(In reply to Jeff Muizelaar [:jrmuizel] from comment #2)

This is a pretty surprising regression given the code changes...

I'm not sure if we have much choice besides swallowing it.

I tried reverting this change. We'll see what the performance numbers look like: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9108700a6bf03fb2ac078f38c9425b1ccb171d23

Reverting the change does seem to move the numbers back. Here's a version that only reverts the shader change:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=930f9c78df42283c7c8dafe611acedd26dc14d52

And only reverting the rust change: https://treeherder.mozilla.org/#/jobs?repo=try&revision=fee287184708a1927f1e7e1b10fe6db57570a705

The conclusion is that the shader change caused this: https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&newProject=try&newRevision=930f9c78df42283c7c8dafe611acedd26dc14d52&framework=1&selectedTimeRange=172800

This is pretty surprising. Perhaps we're causing the shader compiler to be sad.

Since this is Linux only, we're not currently shipping on Linux and Linux's ts_paint_webext and sessionrestore numbers are already about twice as bad with WebRender vs non-WebRender I don't think it's worth investigating a <2% regression.