Talos has detected a Firefox performance regression from push 2e59e89efef982bee73573f6861f50574bab6b84. As author of one of the patches included in that push, we need your help to address this regression. Regressions: 20% basic_compositor_video summary windows8-64 opt e10s 4.46 -> 5.35 17% basic_compositor_video summary windows7-32 opt e10s 4.34 -> 5.1 You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=6034 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
as a note this is a new test and it is hard to determine if this is numbers getting baselined or a real regression- keep that in mind- but we should understand these new tests.
oh, this isn't a new test, I confused this with glvideo! I did see that we backed out the patch from bug 1356448: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0cb37bb22087194306b5656d4b118ba8b0cfee40&tochange=d09143959b1af76d12d4429e92b1cd07544d0bef
and it landed again: == Change summary for alert #6333 (as of May 03 2017 14:10 UTC) == Regressions: 20% basic_compositor_video summary windows8-64 opt e10s 4.46 -> 5.35 For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=6333 looks like it was backed out again as well. Is there a plan to improve the perf regression on this bug when we land it again?
We should probably at least find out where it's coming from. It's possible the video decoding ends up on the compositor process, or that it doesn't, but it should. Matt, if we allow unaccelerated compositor process, what would happen to the video decoding? Would it follow the compositor to that process, or would it stay in the content process?
Yeah, it probably is moving the video decoding into the compositor process (media.gpu-process-decoder is true). It's less obvious why that's a regression, but maybe some of the optimization work we did for basic_compositor_video isn't taking effect for the compositor process path.
David, we disabled video decoding on the compositor process when in software, right? Don't think this regression shows up with the latest landing?
Right I think we're in the clear.