Talos has detected a Firefox performance regression from push f5de44ecf07f . As author of one of the patches included in that push, we need your help to address this regression. This is a list of all known regressions and improvements related to the push: https://treeherder.mozilla.org/perf.html#/alerts?id=909 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#TART.2FCART https://wiki.mozilla.org/Buildbot/Talos/Tests#tsvgx https://wiki.mozilla.org/Buildbot/Talos/Tests#tsvg-opacity https://wiki.mozilla.org/Buildbot/Talos/Tests#tscrollx Reproducing and debugging the regression: If you would like to re-run this Talos test on a potential fix, use try with the following syntax: try: -b o -p win32,macosx64,win64,linux64 -u none -t svgr[Windows XP,Windows 7,10.10,Windows 8],svgr-e10s[Windows XP,Windows 7,10.10,Windows 8] --rebuild 5 # add "mozharness: --spsProfile" to generate profile data (we suggest --rebuild 5 to be more confident in the results) To run the test locally and do a more in-depth investigation, first set up a local Talos environment: https://wiki.mozilla.lorg/Buildbot/Talos/Running#Running_locally_-_Source_Code Then run the following command from the directory where you set up Talos: talos --develop -e [path]/firefox -a cart:tsvgx:tsvgr_opacity:tscrollx (add --e10s to run tests in e10s mode) Making a decision: As the patch author we need your feedback to help us handle this regression. *** Please let us know your plans by Monday, 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
I did a lot of retriggers this morning and ended up with a compare view that aligns fairly well with the generated alerts: https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-inbound&originalRevision=336a70a8dfe4&newProject=mozilla-inbound&newRevision=f5de44ecf07f&framework=1 One concern is the svg related regressions are e10s only, this will need more info from the e10s drivers as there are release criteria for e10s vs non e10s. :mstange, I see you are the patch author. Can you take a look at this and see if there is anything we can do here? Let me know if you want me to bisect on try, I have no problem doing that :)
It's clear from jmaher's comparison view in comment 1 that only non-e10s CART was regressed for Windows 8-64. The e10s performance remains the same.
It's not surprising that these patches affected performance; we're trading performance on some work loads for performance on other work loads. To be specific, if there are multiple invalid rects close to each other, we end up painting more than before, but if there are multiple invalid rects far away from each other, we end up painting less than before. This is caused by the tile size that we chose; it's currently set to 256 but it's possible that a smaller tile size works better. There's something else that might have affected performance here: bug 1236043 triggered a compositor bug on Windows, bug 1266161. We'll need to wait and see what affect fixing that bug will have on our Talos numbers. Once bug 1266161 is fixed, I'll trigger a few try pushes with different tile sizes.
this is now on mozilla-beta!
Just following up here. Could we get a test to see if the different tile sizes helps out with cart/svg ? Even if this doesn't land on beta, it would be nice to determine if there is a possible win and then figure out which branches to put it on.
this has shipped- lets either close this out or take action on it.
:mstange, this is pretty old, is there something to do here?
It would still be nice to check whether a smaller tile size helps.