Talos has detected a Firefox performance regression from push: https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=431fb0d124cdde8423e4af122ef9ff0a1f0e1779 As author of one of the patches included in that push, we need your help to address this regression. Regressions: 7% tps summary osx-10-10 opt e10s 20.02 -> 21.45 You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=9442 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

Dão, can you look over this Talos regression?

So tps measures the "time between switching a tab [sic!] and the first paint to the content area." Does it make sense that bug 1399235 would regress this? How synthetic / representative of real-world performance is this test? How confident are we generally in this test? I find it suspicious that this would affect only OS X 10.10, but maybe we'll get more reports from other platforms later.

(In reply to Dão Gottwald [::dao] from comment #2) > So tps measures the "time between switching a tab [sic!] and the first paint > to the content area." Does it make sense that bug 1399235 would regress > this? How synthetic / representative of real-world performance is this test? > How confident are we generally in this test? I will ni? Joel and the test owners on this. I only report the tests' results. > I find it suspicious that this would affect only OS X 10.10, but maybe we'll > get more reports from other platforms later. You are right. I managed to relate these perf changes to this bug. == Change summary for alert #9458 (as of September 14 2017 11:58 UTC) == Regressions: 12% tresize windows7-32 pgo e10s 9.32 -> 10.45 9% tresize windows7-32 opt e10s 10.86 -> 11.81 Improvements: 28% tart summary linux64 opt e10s 5.79 -> 4.18 27% tart summary linux64 pgo e10s 5.12 -> 3.75 23% tart summary windows7-32 opt e10s 6.90 -> 5.34 22% tart summary windows10-64 opt e10s5.68 -> 4.44 15% tart summary osx-10-10 opt e10s 9.97 -> 8.51 14% tart summary windows10-64 pgo e10s4.43 -> 3.79 12% tart summary windows7-32 pgo e10s 4.95 -> 4.35 For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=9458

tps was added by :blassey and :mconley and I am not sure of the specifics of the test. It basically switches between 50 tabs rapidly and measures the time to first paint in the content of the tab: https://wiki.mozilla.org/Buildbot/Talos/Tests#tps This seems like a useful test in general, although the implementation might require updating as the browser has changed over time.

Bug 1399235 is indeed the source of improving tart. I backed out the change and it regressed 25%. https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&originalRevision=319a34bea9e4&newProject=try&newRevision=884fdb9dbd96c39c9a183069980ea415d57af1f3&framework=1

(In reply to Ed Lee :Mardak from comment #5) > Bug 1399235 is indeed the source of improving tart. I backed out the change > and it regressed 25%. Thanks for checking. There's probably a rational explanation why this regressed some talos tests and improved others by such a large margin, but it's beyond me. If the tps regression is limited to OS X 10.10 and the tresize regression is limited to Win7, I suggest we just wontfix this.

I think I'm able to reproduce this locally. Going to confirm, and then post some profiles.

Okay, I can reproduce this pretty consistently on my local OS X machine. I gathered some profiles: Good (no regression, no patch): https://perfht.ml/2k2ctq3 Bad (regression, with patch): https://perfht.ml/2k0ukhf The "bad" profile shows a pretty long composite, waiting on swap buffers. I wonder if the -moz-hidden-unscrollable rule adds some layering or compositing complexity that wasn't there before? jrmuizel, do you know? Anything jump out at you?

It might be interesting to look at this with layer borders on to see if anything noticeable changes.

jrmuizel and I looked at this today. There are two things we want to try: 1) We want to know _exactly_ which part of the patch caused the regression. We're assuming it was the hidden scrollable stuff, but we should make sure. 2) jrmuizel wants me to add a counter to see how much data is being sent to the compositor and spit it out at the end of the test, and compare with and without the patch.

Also better profile data with start and end markers representing actual measured time.

Mike, do you still want this on your backlog? I notice you set n-i on yourself but this also has P3 set. I'm about to let it drop out of the regression triage query.

Yeah, I never got around to this. :( Let's let it drop for now from the query.