Talos has detected a Firefox performance regression from push: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f46b5589e6039eb12f9b750bb1f6fd4cd5699c22&tochange=50091ebf491862711c143ae5dfbbd26000103eb9 As author of one of the patches included in that push, we need your help to address this regression. Regressions: 75% sessionrestore_many_windows windows10-64 pgo e10s stylo 793.83 -> 1,393.08 73% sessionrestore_many_windows windows7-32 pgo e10s stylo 831.83 -> 1,439.33 65% sessionrestore_many_windows windows10-64 opt e10s stylo 894.08 -> 1,479.42 61% sessionrestore_many_windows windows7-32 opt e10s stylo 978.67 -> 1,572.83 37% tp5o_webext responsiveness windows7-32 pgo e10s stylo 0.87 -> 1.19 31% tp5o_webext responsiveness windows10-64 pgo e10s stylo 0.96 -> 1.25 29% tp5o_webext responsiveness windows10-64 opt e10s stylo 1.07 -> 1.37 27% tp5o_webext responsiveness windows7-32 opt e10s stylo 1.10 -> 1.40 You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=12758 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

:florian Bug 1450293 looks to have caused these huge performance regressions. Must we back it out or can we resolve this?

(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #1) > Must we back it out or can we resolve this? I don't know yet, but investigating this is my top priority. It was already reported yesterday as bug 1454638 which I believe is the same problem, but seen from user perception rather than Talos numbers.

This solves locally the problem I had observed in the profiles from bug 1454638. I'm waiting for try results before requesting review.

Try seems to confirm: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=1497dea029a3b4c6f699cc2533aabe67b927d7fd&newProject=try&newRevision=1b8ad47f881cf80dfaa3e884ca490199ab4d9e1b&framework=1&showOnlyConfident=1

Comment on attachment 8968903 [details] [diff] [review] Patch This patch matches what is already done in 2 other places in the same method: https://searchfox.org/mozilla-central/rev/f65d7528e34ef1a7665b4a1a7b7cdb1388fcd3aa/widget/windows/nsWindowGfx.cpp#188-190,196-198,245-248

Pushed by florian@queze.net: https://hg.mozilla.org/integration/mozilla-inbound/rev/be9efc84b582 do an empty paint when skipping the actual paint for the blank window, to stop Windows from sending messages repeatedly, r=jimm.

I confirm the fix: == Change summary for alert #12810 (as of Wed, 18 Apr 2018 16:46:08 GMT) == Improvements: 42% sessionrestore_many_windows windows10-64 pgo e10s stylo 1,392.33 -> 808.00 41% sessionrestore_many_windows windows7-32 pgo e10s stylo 1,435.92 -> 848.00 39% sessionrestore_many_windows windows10-64 opt e10s stylo 1,475.75 -> 904.00 36% sessionrestore_many_windows windows7-32 opt e10s stylo 1,567.08 -> 995.25 23% tp5o_webext responsiveness windows10-64 pgo e10s stylo 1.21 -> 0.93 23% tp5o_webext responsiveness windows7-32 opt e10s stylo 1.40 -> 1.08 23% tp5o_webext responsiveness windows7-32 pgo e10s stylo 1.18 -> 0.91 21% tp5o_webext responsiveness windows10-64 opt e10s stylo 1.34 -> 1.06 For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=12810