1443401 - 9.62 - 12.14% damp (linux64, osx-10-10, windows10-64, windows7-32) regression on push 84ea422093dd (Mon Mar 5 2018)

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Ionuț Goldan [:igoldan]]

Talos has detected a Firefox performance regression from push:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=84ea422093dd615bd191a3e579ed299d96c802f1

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

Regressions:

 12%  damp windows7-32 pgo e10s stylo     77.83 -> 87.28
 12%  damp windows10-64 opt e10s stylo    98.64 -> 110.60
 12%  damp linux64 opt e10s stylo         54.57 -> 61.19
 11%  damp linux64 pgo e10s stylo         50.39 -> 56.01
 11%  damp osx-10-10 opt e10s stylo       95.28 -> 105.78
 11%  damp windows10-64 pgo e10s stylo    79.39 -> 87.92
 10%  damp windows7-32 opt e10s stylo     101.59 -> 111.37


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

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]]

Marking this as WONTFIX, according to comment from bug 1193394: https://bugzilla.mozilla.org/show_bug.cgi?id=1193394#c162

Comment 2

[Boris Zbarsky [:bzbarsky]]

Alexandre asked to be needinfo'd if this happened.

Looking at https://treeherder.mozilla.org/perf.html#/comparesubtest?originalProject=mozilla-inbound&originalRevision=c842abb7cfbf39e0c1cfb9a1f3a1d6415cd10744&newProject=mozilla-inbound&newRevision=84ea422093dd615bd191a3e579ed299d96c802f1&originalSignature=f79b6a4f1f8f53326d3056f6c8008c0ff4de0a94&newSignature=f79b6a4f1f8f53326d3056f6c8008c0ff4de0a94&framework=1 the specific regressed tests are:

  complicated.netmonitor.reload.settle (1 -> 106)
  simple.memory.reload.settle (1 -> 24)
  simple.netmonitor.reload.settle (2 -> 12)

and there are also improvements:

  cold.inspector.open.settle (16 -> 3)
  custom.jsdebugger.reload.settle (20 -> 1)

Comment 3

[Alexandre Poirot [:ochameau]]

Thanks for the ping.

All these settle subtests are covering what happens right after each subtest.
We record them to help knowing if we suddendly stop waiting correctly for some requests/reflows/...
For now, settle only waits for pending repaints.

I'm not surprised to see such platform patch having an impact on them, but it is clearly not the root cause of having non-zero settle. In theory they should all be 0, or close to 0 if DAMP test scripts were all perfect.