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

Regressions:

491% tp5n main_normal_fileio windows10-64-shippable opt e10s stylo 1,091,037.00 -> 6,449,541.17
24% tp5o_webext macosx1014-64-shippable opt e10s stylo 507.91 -> 629.57
10% tsvgr_opacity macosx1014-64-shippable opt e10s stylo 149.12 -> 163.57
8% tsvgx macosx1014-64-shippable opt e10s stylo 184.94 -> 199.84
8% tp5o macosx1014-64-shippable opt e10s stylo 350.90 -> 377.57
6% tscrollx linux64-shippable-qr opt e10s stylo 1.49 -> 1.57
5% tsvg_static macosx1014-64-shippable opt e10s stylo 58.59 -> 61.44
5% glterrain windows7-32-shippable opt e10s stylo 1.17 -> 1.22
3% tscrollx linux64-shippable opt e10s stylo 0.76 -> 0.78
2% tp5o windows7-32-shippable opt e10s stylo 213.37 -> 218.31
2% tp5o_webext windows7-32-shippable opt e10s stylo 286.71 -> 292.99

Improvements:

7% tp5o_webext responsiveness linux64-shippable-qr opt e10s stylo 2.40 -> 2.22
3% displaylist_mutate linux64-shippable-qr opt e10s stylo 3,144.70 -> 3,056.44
3% tsvgx linux64-shippable-qr opt e10s stylo 210.84 -> 205.35
2% tp5o_webext linux64-shippable opt e10s stylo 274.34 -> 268.82

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.

None of this is particularly surprising. The normal fileio I believe was something that moved from one test number to another (the other number was much bigger so 5MB just wasn't significant), so not a real regression.. for the others it's sort of weird they would occur only on OS X and nowhere else, since there's nothing OS specific about this patch. I suspect the cause is poor measurements that happen to turn out differently because of the extensive timing changed made by bug 1606706.

We have used browsertime to measure extensively if there was actual regressions to the user experience and none were found, for tscrollx I believe we already accept a much bigger regression for WebRender. All in all I don't think there's any major causes for concern, although it would be interesting to understand why these are all showing up on OS X, that's sort of an odd 'coincidence'.

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

Based on comments, not an actual regression.

Some of these seem to have been more or less reversed with the fixing of bug 1652432. (Some of the improvements as well, things are fiddly that way :))

Bas, should I close this as WONTFIX?

(In reply to Bas Schouten (:bas.schouten) from comment #4)

Some of these seem to have been more or less reversed with the fixing of bug 1652432. (Some of the improvements as well, things are fiddly that way :))

Taking this and 3y distance as enough reason to just close this.