1366234 - 2.14% tsvgr_opacity (osx-10-10) regression on push 06bdd79f4ba24041467755b35dab028e06e2de7d (Wed May 17 2017)

Status: RESOLVED WONTFIX

(Core :: WebRTC: Networking, defect)

Description

[Ionuț Goldan [:igoldan]]

Talos has detected a Firefox performance regression from push:

https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=06bdd79f4ba24041467755b35dab028e06e2de7d

As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

  2%  tsvgr_opacity summary osx-10-10 opt e10s     338.28 -> 345.53


You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=6678

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

[Ionuț Goldan [:igoldan]]

:drno Could you confirm this regresssion? Please state if it's something we can fix or accept as is.

Comment 2

[Nils Ohlmeier [:drno]]

(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #1)
> :drno Could you confirm this regresssion? Please state if it's something we
> can fix or accept as is.

The changes I pushed are affecting establishing calls via WebRTC. I really don't see how this could or should affect rendering SVG.

Or in other words: if rendering SVG executes any of the code I touched that something is really wrong here.

So I don't see how this could be a regression. My only guess would be that this most be cause by something else in the test environment.

Comment 3

[Ionuț Goldan [:igoldan]]

Thanks for clarifyng that aspect of the problem.

The fact is this test also tends to reflect changes in network efficiency. You can read more about the test here:
https://wiki.mozilla.org/Buildbot/Talos/Tests#tsvgr_opacity

The WebRTC changes are network related and that's why I opened this bug. With this in mind, could you please review the changes and state whether small optimizations can be made? Or accept this regression?

Comment 4

[Nils Ohlmeier [:drno]]

(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #3)
> Thanks for clarifyng that aspect of the problem.
> 
> The fact is this test also tends to reflect changes in network efficiency.
> You can read more about the test here:
> https://wiki.mozilla.org/Buildbot/Talos/Tests#tsvgr_opacity

Thanks. That link was really helpful in understanding what this test is about.
 
> The WebRTC changes are network related and that's why I opened this bug.
> With this in mind, could you please review the changes and state whether
> small optimizations can be made? Or accept this regression?

You are right about this being network related changes. But this deep down in the WebRTC networking code, which really should be executed ever when we are loading anything via HTTP(S). That's why I really can't think of any reasonable way how the patch could have caused this performance regression.

If there are no other ways to check for environment changes like something which influences the load speed on the Talos machines, then I think we can only accept this new slower value.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Nils Ohlmeier [:drno] from comment #4)

> > The WebRTC changes are network related and that's why I opened this bug.
> > With this in mind, could you please review the changes and state whether
> > small optimizations can be made? Or accept this regression?
> 
> You are right about this being network related changes. But this deep down
> in the WebRTC networking code, which really should be executed ever when we
> are loading anything via HTTP(S). 

Nils meant to say "should never be executed"

> That's why I really can't think of any
> reasonable way how the patch could have caused this performance regression.

Right.