Talos has detected a Firefox performance regression from push: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=84ea422093dd615bd191a3e579ed299d96c802f1 As author of one of the patches included in that push, we need your help to address this regression. Regressions: 12% damp windows7-32 pgo e10s stylo 77.83 -> 87.28 12% damp windows10-64 opt e10s stylo 98.64 -> 110.60 12% damp linux64 opt e10s stylo 54.57 -> 61.19 11% damp linux64 pgo e10s stylo 50.39 -> 56.01 11% damp osx-10-10 opt e10s stylo 95.28 -> 105.78 11% damp windows10-64 pgo e10s stylo 79.39 -> 87.92 10% damp windows7-32 opt e10s stylo 101.59 -> 111.37 You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=11928 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

Marking this as WONTFIX, according to comment from bug 1193394: https://bugzilla.mozilla.org/show_bug.cgi?id=1193394#c162

Alexandre asked to be needinfo'd if this happened. Looking at https://treeherder.mozilla.org/perf.html#/comparesubtest?originalProject=mozilla-inbound&originalRevision=c842abb7cfbf39e0c1cfb9a1f3a1d6415cd10744&newProject=mozilla-inbound&newRevision=84ea422093dd615bd191a3e579ed299d96c802f1&originalSignature=f79b6a4f1f8f53326d3056f6c8008c0ff4de0a94&newSignature=f79b6a4f1f8f53326d3056f6c8008c0ff4de0a94&framework=1 the specific regressed tests are: complicated.netmonitor.reload.settle (1 -> 106) simple.memory.reload.settle (1 -> 24) simple.netmonitor.reload.settle (2 -> 12) and there are also improvements: cold.inspector.open.settle (16 -> 3) custom.jsdebugger.reload.settle (20 -> 1)

Thanks for the ping. All these settle subtests are covering what happens right after each subtest. We record them to help knowing if we suddendly stop waiting correctly for some requests/reflows/... For now, settle only waits for pending repaints. I'm not surprised to see such platform patch having an impact on them, but it is clearly not the root cause of having non-zero settle. In theory they should all be 0, or close to 0 if DAMP test scripts were all perfect.