Closed Bug 1356554 Opened 8 years ago Closed 8 years ago

17.43 - 19.88% basic_compositor_video (windows7-32, windows8-64) regression on push 2e59e89efef982bee73573f6861f50574bab6b84 (Fri Apr 14 2017)

Categories

(Core :: Graphics, defect)

Unspecified
Windows
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
firefox52 --- unaffected
firefox-esr52 --- unaffected
firefox53 --- unaffected
firefox54 --- unaffected
firefox55 --- fixed

People

(Reporter: igoldan, Assigned: milan)

References

Details

(Keywords: perf, regression, talos-regression)

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
Component: Untriaged → Graphics
Product: Firefox → Core
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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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?
Flags: needinfo?(matt.woodrow)
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.
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(milan)
David, we disabled video decoding on the compositor process when in software, right? Don't think this regression shows up with the latest landing?
Flags: needinfo?(milan) → needinfo?(dvander)
Right I think we're in the clear.
Flags: needinfo?(dvander)
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.