Talos has detected a Firefox performance regression from push: https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=393eadbb146f As author of one of the patches included in that push, we need your help to address this regression. Regressions: 2% damp summary windows7-32 opt e10s 257.84 -> 263.21 You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=8795 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

Kevin, I see you authored the patch in bug 1325080, can you look at this and determine why the devtools (damp) test regressed- ideally figuring out if there is a way to improve this regression?

It could be that synchronously loading images affects the loading of icons in devtools. I'm going to try backing out the changeset, and then patching with more limited scope (data URIs only).

Specifically, the regression is in all of the ".open" subtests (most of which were between 12% and 19% regressions). Here's the subtest breakdown: https://treeherder.mozilla.org/perf.html#/comparesubtest?originalProject=autoland&originalRevision=e5dfbde553d607218fea30f109484ecd64b1532a&newProject=autoland&newRevision=086e30b2dfabd588c036bb1b8dae657a4b887a47&originalSignature=63c652b34bd8fcf3623be048bdd3104906f70f02&newSignature=63c652b34bd8fcf3623be048bdd3104906f70f02&framework=1 As extra validation that the regression is "real", it looks like we got the same regressions on Inbound as well when this was merged over there (as part of https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=ae73a8a8bc05 ): https://treeherder.mozilla.org/perf.html#/comparesubtest?originalProject=mozilla-inbound&originalRevision=9b101cdb3935c224f97a4f1e6de642c0ca5c3c5e&newProject=mozilla-inbound&newRevision=ae73a8a8bc05a43250e8261042c931c02a73bd25&originalSignature=63c652b34bd8fcf3623be048bdd3104906f70f02&newSignature=63c652b34bd8fcf3623be048bdd3104906f70f02&framework=1 The inbound subtest view doesn't highlight the regressions in red as much, but it does show similar regressions (mostly in the 12-19% range) on all the same ".open" subtests that are highlighted on the autoland subtest page.

(Once the tree reopens, I'm going to back out the regressing patch and I'll close this as FIXED-by-backout, and Kevin's going to follow up with a more targeted patch on bug 1325080.)

Resolving as FIXED by backout in bug 1325080 comment 43.

Just to follow up here -- the backout definitely did fix this, and the re-landing didn't reintroduce the bug. Hooray! Here's a graph of just the first subtest that regressed: https://treeherder.mozilla.org/perf.html#/graphs?highlightedRevisions=e5dfbde553d6&highlightedRevisions=086e30b2dfab&series=%5B%22autoland%22,%22d15b5a9ae62647bae61f716e3e9fcff5a36c829b%22,1,%221%22%5D&timerange=1209600 There's a very pronounced increase in that graph when this bug regressed (Aug 15), and very clear return-to-baseline a few days later, which is on the push that includes the backout being merged over to autoland). And it stayed at the baseline after the relanding (which was very shortly after the backout).