Joel Maher ( :jmaher ) (UTC -8) Reporter
	Description • 8 years ago

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

Summary of tests that regressed:

  a11yr summary windows8-64 opt: 600.99 -> 613.2 (2.03% worse)
  tp5o summary osx-10-10 opt e10s: 273.26 -> 277.55 (1.57% worse)
  tart summary windows7-32 opt e10s: 6.49 -> 6.65 (2.41% worse)
  tp5o summary windows7-32 opt: 361.5 -> 370.12 (2.38% worse)
  tp5o summary linux64 opt: 337.83 -> 346.85 (2.67% worse)
  tp5o responsiveness linux64 opt: 49.27 -> 51.64 (4.81% worse)
  tscrollx summary linux64 opt: 7.22 -> 7.44 (3.05% worse)
  a11yr summary windows8-64 opt e10s: 592 -> 599.44 (1.26% worse)
  tart summary windows8-64 opt e10s: 6.01 -> 6.15 (2.45% worse)
  tp5o responsiveness linux64 pgo: 29.55 -> 30.87 (4.48% worse)
  tp5o summary linux64 pgo: 251.36 -> 257.42 (2.41% worse)
  tart summary windows8-64 pgo e10s: 4.97 -> 5.07 (2.13% worse)


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

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

	Joel Maher ( :jmaher ) (UTC -8) Reporter
	Comment 1 • 8 years ago

:mstange, I did a lot of retriggers here and have a compare view to look at subtests:
https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-inbound&originalRevision=4b7cd5b39cca&newProject=mozilla-inbound&newRevision=b1dbce81bf3b&framework=1

this is a collection of regressions- I assume some of this makes sense to you and possibly there are a few things you can think of to reduce these performance regressions?

	Markus Stange [:mstange] Assignee
	Comment 2 • 8 years ago

Thank you Joel. My hope was that the improvements to the patch in bug 1012752 that I've made in the meantime would have fixed this regression, but apparently they haven't. I'll need to do some profiling locally.
Bug 1012752 was supposed to improve performance, not regress it.

	Joel Maher ( :jmaher ) (UTC -8) Reporter
	Comment 3 • 8 years ago

:mstange, any updates on this bug?

	Markus Stange [:mstange] Assignee
	Comment 4 • 8 years ago

Not yet, sorry. Still on my list.

	Joel Maher ( :jmaher ) (UTC -8) Reporter
	Comment 5 • 8 years ago

as a note, we will merge this to aurora next week.

	Markus Stange [:mstange] Assignee
	Comment 6 • 8 years ago

I tried reproducing the tscrollx regression on Linux yesterday, but was not successful. And in the time between the regressing patch landed and now, we enabled GL acceleration on Linux, so the performance characteristics of the tscroll tests are now completely different.
I'll have to take a look at the Windows regressions. Probably by pushing to try with logging.

	Joel Maher ( :jmaher ) (UTC -8) Reporter
	Comment 7 • 8 years ago

:mstange, do you have any updates here?

	Astley Chen (inactive)
	Comment 8 • 8 years ago

Markus, I'm not seeing any unresolved dependent bugs here. Is this bug WIP now ?

	Jet Villegas (inactive)
	Comment 9 • 8 years ago

Joel: can we get new Talos numbers now that bug 1310900 has landed?

	Markus Stange [:mstange] Assignee
	Comment 10 • 8 years ago

I looked at some numbers after that bug landed and couldn't find any improvements. I think there's still work left to do here.

	Markus Stange [:mstange] Assignee
	Comment 11 • 8 years ago

The reason that I'm not prioritizing this very much is that the patch that caused this regression greatly improved the performance of scrolling to the bottom edge of a document, and I'm pretty sure that the benefits from it outweigh this regression.

	Joel Maher ( :jmaher ) (UTC -8) Reporter
	Comment 12 • 8 years ago

looking on trunk (this regression is on aurora) for improvements around the 18th, I see most of the tp5o tests improved and win8 tart, all from this original list:
https://treeherder.mozilla.org/perf.html#/alerts?id=2274

it is hard to say if these are specific to the fix, but there is a noticeable bump around the 18th.  It isn't large enough to generate an alert though.

	Joel Maher ( :jmaher ) (UTC -8) Reporter
	Comment 13 • 8 years ago

I am not sure if we should accept this as wontfix given that we will be on BETA soon and any fixes will land on trunk- probably a smaller chance of them getting ported to beta- I will follow up when we get to BETA in a week (probably more like 1.5-2 weeks)

	Gerry Chang [:gchang]
	Comment 14 • 8 years ago

Hi Astley,
Can you help follow-up on this one? Thanks.

	Astley Chen (inactive)
	Comment 15 • 8 years ago

Per comment 11, update to P3.

	Joel Maher ( :jmaher ) (UTC -8) Reporter
	Comment 16 • 7 years ago

:mstange, this is an old bug, it isn't clear if there is work to do here- Since this is shipped, can we close this out?

	Markus Stange [:mstange] Assignee
	Comment 17 • 7 years ago

We shipped it, but we should still fix it.

I think shipping this was definitely beneficial over backing the regressing patch out, because that patch fixed a much more severe performance problem. But there's room for improvement.

Specifically, we should cache the scroll frame's layer resolution on the scroll frame and invalidate it at the right times, instead of trying to look up the layer so frequently.

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 18 • 7 years ago

I leave this in mstange's backlog; it may or may not still be affecting 54/55. 
Too late for a fix for 53 though.

	Joel Maher ( :jmaher ) (UTC -8) Reporter
	Comment 19 • 7 years ago

checking in here- Is this something realistic to do, or should we assume enough time has gone by that any fixes/plans would be obsolete with test/code changes