Perfherder has detected a talos performance regression from push 63b8480782c85e2365d5fa9486c32b7ab223e998. As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

8% tp5o_webext responsiveness linux64-shippable-qr opt e10s stylo 2.26 -> 2.45
8% tp5o_webext responsiveness linux64-shippable-qr opt e10s stylo 2.28 -> 2.46
4% tp5o_webext linux64-shippable opt e10s stylo 269.70 -> 280.37
3% tp5o_webext linux64-shippable-qr opt e10s stylo 265.86 -> 274.94

Improvements:

18% tp5o_webext macosx1014-64-shippable opt e10s stylo 628.73 -> 514.00
8% tsvgr_opacity macosx1014-64-shippable opt e10s stylo 163.88 -> 150.93
6% tp5o macosx1014-64-shippable opt e10s stylo 375.38 -> 353.34

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the offending patch(es) will be backed out in accordance with our regression policy.

For more information on performance sheriffing please see our FAQ.

Set release status flags based on info from the regressing bug 1650629

(In reply to Alexandru Ionescu (needinfo me) [:alexandrui] from comment #0)

[...] the offending patch(es) will be backed out

So users will get 0,5-10s hangs again on opening various website pages, not good idea.

I suspect this is just the opposite of bug 1650397 :). But not all things reported yet.

[QF triage]: Bas: now that some time has passed since this was filed, do we have any more information about what the best next-action is here? (And is this a real regression, or are we just shifting some work around in a way that makes some things faster & other things slower, or something else?)

Yeah, this is just due to fixing a bug that we introduced in the initial landing of the scheduler. With that in mind, closing.