1462296 - 4.17 - 7.24% tart (linux64, linux64-qr) regression on push fd84333ffe760d3fdb151e2d79316c69743f3129 (Wed May 16 2018)

Status: RESOLVED WONTFIX

(Core :: Graphics, defect, P3)

Description

[Ionuț Goldan [:igoldan]]

Talos has detected a Firefox performance regression from push:

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

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

Regressions:

  7%  tart linux64-qr opt e10s stylo     1.49 -> 1.59
  5%  tart linux64 opt e10s stylo        2.02 -> 2.12
  4%  tart linux64 opt e10s stylo        2.02 -> 2.11


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

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

:mattwoodrow Bug 1371668 caused some big regressions. Can we cancel them with a fix? Or should we consider accepting/backing them out?

Comment 2

[Ionuț Goldan [:igoldan]]

Here are the Gecko profiles:

right before bug 1371668: https://perf-html.io/from-url/https%3A%2F%2Fqueue.taskcluster.net%2Fv1%2Ftask%2Fa_n0UyjVQzWZ369Fc93Jmw%2Fruns%2F0%2Fartifacts%2Fpublic%2Ftest_info%2Fprofile_tart.zip

bug 1371668: https://perf-html.io/from-url/https%3A%2F%2Fqueue.taskcluster.net%2Fv1%2Ftask%2FQTzFNPxWSbmVVeFeK5pHKQ%2Fruns%2F0%2Fartifacts%2Fpublic%2Ftest_info%2Fprofile_tart.zip

Comment 3

[Matt Woodrow (:mattwoodrow)]

The patch in bug 1371668 just changed the timings of when we paint. Previously, if the compositor is taking longer than painting, we'd paint synchronously in response to the DidComposite message (without waiting for the next vsync/refresh driver tick). Now we just wait for the next tick.

In the normal case, where ticks are aligned to vsync, then we expect this to give better behaviour.

In the ASAP mode used by talos, it's not surprising that delaying the paint (even if the next tick comes quickly) slows us down a bit.

I can't see any actual regressions in the profiles, so I think this is just a measurement difference specific to ASAP mode and not an indication of an actual performance regression.

I think we should just accept this for now.