16.37 - 19.36% tscrollx (linux64) regression on push 7796783a9de9 (Thu Feb 9 2017)

Assigned to



2 years ago
4 months ago


(Reporter: jmaher, Assigned: mstange)


({perf, regression, talos-regression})

53 Branch
perf, regression, talos-regression
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




2 years ago
Talos has detected a Firefox performance regression from push 7796783a9de9. As author of one of the patches included in that push, we need your help to address this regression.


 19%  tscrollx summary linux64 pgo e10s     3.62 -> 4.32
 16%  tscrollx summary linux64 opt e10s     3.73 -> 4.34

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

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

2 years ago
:mstange, can you look into this?  Based on the change, would this be expected?  I didn't see anything in bug 1336519 to indicate this was expected.

Luckily this is only linux64 e10s, so it is narrowed down nicely.
Flags: needinfo?(mstange)

Comment 2

2 years ago
oh, I was being sloppy and now I see win8/win7 as well when looking at the graphs.  For osx, I see a slight change, but nothing large enough to report an alert.

Comment 3

2 years ago
Is this the inverse of bug 1298218 comment 104? If so, then this is expected, see bug 1298218 comment 105. If the numbers are worse than pre bug 1298218 however, then there is something we need to fix here.
Flags: needinfo?(mstange) → needinfo?(jmaher)

Comment 4

2 years ago
we took one step forward on feb 6, and two steps back yesterday.  we had a small improvement and a larger regression (about twice the size of the improvement).
Flags: needinfo?(jmaher)

Comment 5

2 years ago
Ok, that needs to be fixed then. Thanks for checking!
Assignee: nobody → mstange
Component: Untriaged → Layout: Web Painting
Product: Firefox → Core

Comment 6

2 years ago
checking in here, any updates
Flags: needinfo?(mstange)

Comment 7

2 years ago
I have a hunch that removing one special case in the layerization algorithm is going to fix the regression for e10s, at the cost of slightly worse layerization for non-e10s (actually non-APZ). I've pushed that patch to try:

Baseline: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f579a4d338ca6d99fdcaecd1609f0f501c8dce8d
With that one if case removed: https://treeherder.mozilla.org/#/jobs?repo=try&revision=39bee106d6d464b96ab7e4a2d6f2f6a5d690004a

I expect the e10s numbers to improve and the non-e10s numbers to regress with that patch.
Flags: needinfo?(mstange)
Are you going to get back to this Markus? How relevant do you think it is to real-world scrolling performance?

I'm assuming low, so setting P3.
Priority: -- → P3

Comment 10

4 months ago
Oh, I had completely forgotten about this bug. It seems to be restricted to background-attachment:fixed sites at least, so it shuoldn't be all that common. But I'd still like to know what's going on; the slowdown means that our layerization is imperfect on those sites.
You need to log in before you can comment on or make changes to this bug.