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)

53 Branch
defect

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
: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)
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.
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)
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)
Ok, that needs to be fixed then. Thanks for checking!
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Component: Untriaged → Layout: Web Painting
Product: Firefox → Core
checking in here, any updates
Flags: needinfo?(mstange)
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
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.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.