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

Status: RESOLVED FIXED

Description

[Ionuț Goldan [:igoldan], Performance Sheriffing]

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

Comment 1

[Joel Maher ( :jmaher ) (UTC-4)]

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.

Comment 2

[Joel Maher ( :jmaher ) (UTC-4)]

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

Comment 3

[Joel Maher ( :jmaher ) (UTC-4)]

this is fixed as we backed this out:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=297b5b4a46caaa71f55d5f1e0daf16f0bebfdc03&tochange=aeea139bf767767356f814943fe92f8471d8f11f

Comment 4

[Joel Maher ( :jmaher ) (UTC-4)]

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?

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

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?

Comment 6

[Matt Woodrow (:mattwoodrow)]

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.

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

David, we disabled video decoding on the compositor process when in software, right?  Don't think this regression shows up with the latest landing?

Comment 8

[David Anderson [:dvander] - inactive, e-mail if emergency]

Right I think we're in the clear.