Talos has detected a Firefox performance regression from push:

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

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

Regressions:

109% glterrain windows10-64-shippable-qr opt e10s stylo 1.15 -> 2.40
54% tscrollx windows10-64-shippable-qr opt e10s stylo 0.82 -> 1.27
52% tscrollx windows10-64-shippable-qr opt e10s stylo 0.83 -> 1.26
41% tart windows10-64-shippable-qr opt e10s stylo 2.46 -> 3.46

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

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/TestEngineering/Performance/Talos

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

This is an expected regression as in Bug 1592509 Comment 3 and Bug 1595437 Comment 13.

:gw, can you comment to the bug?

Yep, those are expected regressions (for now, at least).

We know that we want to use DirectComposition where possible, going forward. It will provide a number of power and performance improvements overall. Getting it enabled now allows us time to work out any visual (and performance regressions).

For these specific performance regressions, there's two possible outcomes, either:

(1) This is a relevant performance regression, related to what appears to be higher than expected GPU usage in the DWM process. We're investigating this now (it's being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1602803).

(2) It also appears from profiling that DC mode has some level of fixed overhead, and that tests with vsync disabled, running at low resolutions do regress in this mode. If that is the case, we're OK with this regression as it's not relevant to real world performance.

Once we resolve the bug in (1) we'll have a better idea if we need to do anything extra here, based on if those fixes change these numbers.

This patch (https://bugzilla.mozilla.org/show_bug.cgi?id=1603314) resolves these regressions. However, I'm going to experiment with some other possible solutions that be a better way to achieve it (see https://bugzilla.mozilla.org/show_bug.cgi?id=1602803#c9 for context).

Bug 1604088 disabled DirectComposition, so I believe this regression should be gone. NI Marian to confirm.

Glenn, do you want to keep this bug open assuming that's the case or should we track follow-up work in the other bugs you referenced?

Yep, we can close this (the regression is gone - if it returns when we re-enable compositor we can open a new bug).

I confirm the regression is gone:

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1604088

Changeset
https://hg.mozilla.org/integration/autoland/rev/b85d5793f58d

Graph:
https://treeherder.mozilla.org/perf.html#/graphs?highlightAlerts=1&selected=1927519,613070,1028.8852878264581,181.12575702371421,1000978783&series=autoland,1927519,1,1&series=mozilla-inbound,1950177,1,1&timerange=1209600

Thanks!