Closed Bug 1527255 Opened 6 years ago Closed 6 years ago

67.51% tp5n nonmain_normal_netio (windows10-64) regression on push 0277af3f283dd3411626b4877b29b2a9530854fa (Mon Feb 11 2019)

Categories

(Testing :: General, defect)

Version 3
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: Bebe, Unassigned)

References

Details

(Keywords: perf, regression, talos-regression, Whiteboard: infrastructure)

Talos has detected a Firefox performance regression from push:

https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=0277af3f283dd3411626b4877b29b2a9530854fa

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

Regressions:

68% tp5n nonmain_normal_netio windows10-64 opt e10s stylo 89,185,041.33 -> 149,390,037.00

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

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/Performance_sheriffing/Talos/Tests

For information on reproducing and debugging the regression, either on try or locally, see: https://wiki.mozilla.org/Performance_sheriffing/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/Performance_sheriffing/Talos/RegressionBugsHandling

Blocks: 1522900, 1521698

:jmaher Bug 1522900 created a performance regression can you take a look please

Flags: needinfo?(jmaher)

This is not a real Firefox perf regression. What we're interested here is whether these results were expected or not, as this is a harness update.

this wasn't known about before, so not expected. As this didn't change any firefox code, test code, only infra- there is really nothing to do here.

Given that this is nonmain normal netio, I suspect the difference is that on windows10 v1803 we do more dynamic fonts which could be queried via the network interface. Likewise maybe there is more or different patterns with the file cache and related browsing we do. We don't have a straightforward way to get more data on this- typically I push before/after to try with some hacks for xperf, but in this case I don't have access to a v1703 vm- we can spin one up and test this if it is important.

One thing that would be interesting is when we upgrade the hardware machines to 1803 what will the perf results be.

:igoldan, do you have other thoughts on how to understand this or next steps?

Flags: needinfo?(jmaher) → needinfo?(igoldan)

(In reply to Joel Maher ( :jmaher ) (UTC-4) from comment #3)

this wasn't known about before, so not expected. As this didn't change any firefox code, test code, only infra- there is really nothing to do here.

Given that this is nonmain normal netio, I suspect the difference is that on windows10 v1803 we do more dynamic fonts which could be queried via the network interface. Likewise maybe there is more or different patterns with the file cache and related browsing we do. We don't have a straightforward way to get more data on this- typically I push before/after to try with some hacks for xperf, but in this case I don't have access to a v1703 vm- we can spin one up and test this if it is important.

One thing that would be interesting is when we upgrade the hardware machines to 1803 what will the perf results be.

:igoldan, do you have other thoughts on how to understand this or next steps?

I believe this is sufficient.

Flags: needinfo?(igoldan)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Whiteboard: infrastructure
You need to log in before you can comment on or make changes to this bug.