1546313 - YouTube with Polymer v3.2.0 is loading slower than with Polymer v1.x

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[tgn-ff]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

1. Open Firefox with a new and clean profile.
2. Open a Private Window and load YouTube. Repeat until you get the Polymer.version (type than in the console) 3.2.0.
3. Reload and take note of the needed time.
4. Compare the time with the Polymer.version 1.x.

Actual results:

About three times more time is needed for the YouTube page to load with the Polymer.version@3.2.0 versus the Polymer.version@1.x.

Expected results:

It should be, if not faster, at least equal.

This is a regression on Firefox's side. Bisection points to Bug 1504947.

Mozregression:
27:08.26 INFO: No more inbound revisions, bisection finished.
27:08.26 INFO: Last good revision: e9408a26af674fbf535d853ede4ab629ac652c05
27:08.26 INFO: First bad revision: 8eaa269b362fd429c04779eaff8e2e7cd0075ad7
27:08.26 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e9408a26af674fbf535d853ede4ab629ac652c05&tochange=8eaa269b362fd429c04779eaff8e2e7cd0075ad7

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Seems like an odd cause if the bisect is correct, but we'd really hope that dropping the old polyfill will have sped things up, not slowed them down. This is a high visibility issue, of course. We could also use a confirmation, and profiles of load with and without the revision

Comment 2

[Steven DeTar [:sdetar]]

Jeff, see Randell's comments.

Comment 3

[tgn-ff]

I re-ran the bisection and reached to the same result as before. Although, it, now, seems that a simple refresh (F5) might not necessarily be worse - a hard refresh (Ctrl+Shift+R) or opening a video page always exhibits the bad behavior.

As requested, I captured the performance profiles under Polymer 3.2.0. Both are about 5sec before a reload and about 5sec after the page is fully loaded and rendered.
Last good revision: https://perfht.ml/2GU28Ga
First bad revision: https://perfht.ml/2GVbhOW

I can't seem to be able to get the Polymer 1.11.3 version right now. Tell me if it's needed and I can try later.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

This smells a little bit like LSNG - the profile shows a long gap after starting to load the page. However, that landed IIRC March 8th

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Could you try setting dom.storage.next_gen = false, restart the browser, and retest? Thanks!

Comment 6

[Jeff Walden [:Waldo]]

This is fairly clearly due to an algorithmic change in the JS engine, to compute column numbers as counts of code points, not code units. The latter requires some manner of iterating from the start of each line through code units, to compute a count. The latter was just a subtraction and potentially a division by 2. There's nothing particular to investigate here -- except whether some particular characteristic of the relevant source text is worth considering as heuristic when optimizing this.

This is probably a duplicate of all the other open regressions from bug 1504947.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

BTW, my understanding from youtube is that they're now at 100% 3.2 Polymer, so doing a/b comparisons against 1.* won't be possible

My high-end linux profile of this case doesn't show the long gap in the middle of loading -- and I don't see any significant CPU use in unusual threads (using perf, since I can't get Gecko Profiler to work right now in nightly Mac or Linux with private windows - even though it's greenlighted for private windows. The gap makes me think whatever is taking the time isn't on MainThread. Jeff - does the impact of bug 1504947 happen on other threads? if so, we can look for them in profiles.

Comment 8

[Jeff Walden [:Waldo]]

I believe the DOM script loader code compiles scripts off the main thread, so yes, you'd see effects there.

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

If we can get a profile (I can't capture Gecko Profiles with Private Windows open for some reason), we'd want to add "HTML" and "Quota" to the list of threads (they're substring-matched).
Also: OffMainThread parsing is blocked by major GCs... that's another possibility. The second (bad) profile has a GCMajor -- but not in the gap, it's in the area after the gap (when JS is running). The first (good) profile has no GCMajor during the load. So that doesn't really explain the multi-second gap

Comment 10

[tgn-ff]

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #9)

we'd want to add "HTML" and "Quota" to the list of threads (they're substring-matched).

Here you go:
Last good revision: https://perfht.ml/2V7PBIb
First bad revision: https://perfht.ml/2Va7XZ0

Also, setting dom.storage.next_gen to false didn't have any positive or negative effect.

Comment 11

[Chris Peterson [:cpeterson]]

(In reply to tgn-ff from comment #0)

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e9408a26af674fbf535d853ede4ab629ac652c05&tochange=8eaa269b362fd429c04779eaff8e2e7cd0075ad7

Before I discovered this bug report, I bisected this YouTube slowdown with mozregression (on Windows 10) and independently landed on this exact same regression range pointing to bug 1504947.

Comment 12

[Stuart Philp :sphilp]

Our recorded youtube page should be on the old version, if you've run raptor it should be in the ../testing/mozproxy directory. Might be of some use

Comment 13

[Ted Campbell [:tcampbell]]

The backout is on nightly. If there are still concerns here for FF68 we should make sure they are identified.

Comment 14

[tgn-ff]

As far as the reported regression goes, everything seems good on my end.

Comment 15

[Ted Campbell [:tcampbell]]

Thanks for verifying! :)

Comment 16

[Andrew Overholt [:overholt]]

Julien, given comment 14, should we untrack for 68 (and presumably keep this open while Waldo finishes work (comment 6)(?

Comment 17

[Jeff Walden [:Waldo]]

Fixed by the reversion in bug 1549758, which makes the columnAt function in the profile in comment 10 contain purely constant-time operations. Bug 1551916 will have patches that will address the concern in the future.