Open
Bug 1338579
Opened 8 years ago
Updated 3 years ago
16.37 - 19.36% tscrollx (linux64) regression on push 7796783a9de9 (Thu Feb 9 2017)
Categories
(Core :: Web Painting, defect, P3)
Tracking
()
ASSIGNED
People
(Reporter: jmaher, Assigned: mstange)
References
Details
(Keywords: perf, regression, talos-regression)
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.
Regressions:
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
Reporter | ||
Comment 1•8 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)
Reporter | ||
Comment 2•8 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.
Assignee | ||
Comment 3•8 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)
Reporter | ||
Comment 4•8 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)
Assignee | ||
Comment 5•8 years ago
|
||
Ok, that needs to be fixed then. Thanks for checking!
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Updated•8 years ago
|
Component: Untriaged → Layout: Web Painting
Product: Firefox → Core
Assignee | ||
Comment 7•8 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)
Assignee | ||
Comment 8•8 years ago
|
||
Comparison: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=f579a4d338ca6d99fdcaecd1609f0f501c8dce8d&newProject=try&newRevision=39bee106d6d464b96ab7e4a2d6f2f6a5d690004a&framework=1&filter=tscrollx&showOnlyImportant=0
The result is that my hunch was probably wrong. This patch made no difference.
I'm going to focus on the test tscrollx tiled-fixed-downscale.html on linux64 e10s opt. Bug 1298218 reduced the time in that test from 2.74 to 1.53 [1] and then bug 1336519 increased it from 1.60 to 4.41 [2].
[1] https://treeherder.mozilla.org/perf.html#/comparesubtest?originalProject=autoland&originalRevision=38d9a0fa515abfc32aced8d09704d40c47c6ef23&newProject=autoland&newRevision=5746c9b9db68fc00cce51b6cd873f403e0caaee6&originalSignature=f877b07fca1e5b5d304ba4c3d2f0c5e550dfe3e6&newSignature=f877b07fca1e5b5d304ba4c3d2f0c5e550dfe3e6&framework=1
[2] https://treeherder.mozilla.org/perf.html#/comparesubtest?originalProject=autoland&originalRevision=d2eb1c66346f716966e618b68886f7a7dd02f902&newProject=autoland&newRevision=7796783a9de92b38e7f0e9cb4cba840daaf7fd84&originalSignature=f877b07fca1e5b5d304ba4c3d2f0c5e550dfe3e6&newSignature=f877b07fca1e5b5d304ba4c3d2f0c5e550dfe3e6&framework=1
Comment 9•7 years ago
|
||
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
Assignee | ||
Comment 10•7 years 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.
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•