1402220 - 2.65 - 4.77% ts_paint / ts_paint_webext (windows10-64, windows7-32) regression on push 757ae5e740f21d0c703233173422efd4fce7b501 (Thu Sep 21 2017)

Status: RESOLVED WONTFIX

(Core :: Graphics: Layers, defect, P3)

Description

[Ionuț Goldan [:igoldan]]

Talos has detected a Firefox performance regression from push:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=757ae5e740f21d0c703233173422efd4fce7b501

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

Regressions:

  5%  ts_paint windows10-64 pgo e10s     476.67 -> 499.42
  4%  ts_paint_webext windows10-64 pgo e10s538.54 -> 559.42
  3%  ts_paint windows10-64 opt e10s     566.88 -> 585.83
  3%  ts_paint windows7-32 opt e10s      669.33 -> 687.08


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

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

David, I see you are the owner for this bug 1380462. Can you please look over these ts_paint regressions on Windows?

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

There was no performance improvement when bug 1361257 landed - and I hadn't expected one. bug 1380462 backs that bug out, and I wouldn't expect that to change painting performance either. So it's odd that it shows up in Talos now.

The enhancement (bug 1361257) was fairly low priority, and at the moment I don't have time to investigate why the resizing breaks (bug 1380462). I'd rather just take the Talos hit. But if we don't care about the resizing issue we can also backout the backout.

Comment 3

[Kris Maglione [:kmag]]

A 20ms ts_paint hit is a pretty big deal.

Is there any way we can leave this enabled only until first paint?

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

I tried that and it had no effect: https://treeherder.mozilla.org/#/jobs?repo=try&revision=02996cf4ba9b077d0cd7d500f1cc3634e2c9f7c3

Comment 5

[Kris Maglione [:kmag]]

(In reply to David Anderson [:dvander] from comment #4)
> I tried that and it had no effect:
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=02996cf4ba9b077d0cd7d500f1cc3634e2c9f7c3

I'm not sure that's enough. I think we probably need to keep the old behavior enabled until whatever event currently corresponds to talos's idea of first paint happens (which doesn't exactly correspond to layout's idea of first paint).

I don't have a decent Windows development environment to debug with right now, but my guess is that there's a resize happening before that point and forcing an extra layout flush during startup.