Talos has detected a Firefox performance regression from push: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=96115b59fa4db7d4d235982f6993c396aaeb7453&tochange=be009d297bc6c4883a1bbf522001d9bbbc847331 As author of one of the patches included in that push, we need your help to address this regression. Regressions: 5% rasterflood_svg windows7-32 pgo e10s stylo 14,727.11 -> 15,480.00 4% rasterflood_svg linux64 pgo e10s stylo 18,094.33 -> 18,757.00 3% rasterflood_svg windows7-32 opt e10s stylo 15,794.77 -> 16,310.67 2% rasterflood_svg linux64 opt e10s stylo 17,341.33 -> 17,766.17 1% rasterflood_svg osx-10-10 opt e10s stylo 12,457.11 -> 12,636.33 You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=11562 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

:rhunt I'm more than 80% sure bug 1436723 caused this regression. I retriggered the perf tests, to confirm this. Please re-investigate the landed bug, to lessen this performance hit. Do you consider backing this out?

Yeah I'm sure that patch is to blame as well. Let me do some quick profiling to see what the issue here is, before backing it out.

Okay, so I've finally been able to get some results on this. The patches in question added back surface caching on SVG filters (which was removed for P-OMTP) and added a mutex to guard them. This was done to mitigate degenerate situation causing paints to be extremely long with some filters. From doing comparison runs on Skia/Win7 (where there is the greatest difference) and profiling them, I wasn't able to see much of a difference. There was no significant time spent contending the new mutex which was my fear. The most significant difference was that NtFreeVirtualMemory was ~4% of samples versus ~1% of samples. I believe this to be because surface caching can sometimes allocate extra surfaces if the cached rect isn't the desired size, and this may be happening frequent enough to make a difference. Because this would be preexisting behavior that was just restored, not necessarily a bug, and done to mitigate worst case behavior which was affecting real sites, my disposition is to accept this. I only write this now in case there is a question to back this out over the long weekend. I still need to confirm this is the case, but it is likely.