1654087 - reddit.com: slow page performance after scrolling through a lot of pages

Status: RESOLVED FIXED

(Core :: Performance: General, defect, P3)

Description

[Mike Taylor [:miketaylr]]

Originally reported @ https://github.com/webcompat/web-bugs/issues/54958

There is a profile recorded by the OP @ https://profiler.firefox.com/public/fa68768f9ea4bd9a438d12d71b2d0dd6842e1dd0/calltree/?globalTrackOrder=0&thread=0&v=4

Comment 1

[Denis Palmeiro [:denispal]]

I can reproduce this after scrolling about 30 pages. Afterwards, each page scrolled in firefox takes forever to load.

A couple profiles:
https://share.firefox.dev/3fi5rVE
https://share.firefox.dev/3hLShSk

A lot of time spent in js::AtomizeString but main problem may be spending a lot of time loading many mp4's.
It's not super smooth in Chrome, but the delays are much much shorter around a few seconds. In Firefox, the delay can be up to 10s+ for the next page to show up.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Lots of timeupdate events. Are we possibly dispatching them more often than Chrome?

Comment 3

[Denis Palmeiro [:denispal]]

Unfortunately I cannot attach the chrome profile because it is 55MB, but in Chrome many of the functions like experimentEligibilitySelector are only about 20ms, while they are 200-300ms in Firefox. This seems to be mostly because the self time for experimentEligibilitySelector is spent in js::AtomizeString.

Ted, do you know if it's normal to see so many atomize calls and them taking this long to execute?

Comment 4

[Jan de Mooij [:jandem]]

(In reply to Denis Palmeiro [:denispal] from comment #3)

Ted, do you know if it's normal to see so many atomize calls and them taking this long to execute?

I investigated this a bit. I'm assuming I was looking at the same thing...

I saw a lot of strings with length 1897 being atomized there (some kind of IDs), but often the same JSString*. Atomizing that many characters is pretty slow and I think the JS code here has an array of them that it's filter()ing, so the problem gets worse the more posts it's loading.

It's probably worth adding a JSString* => JSAtom* cache, at least for long strings, to make atomizing the same string repeatedly an O(1) operation instead of O(n). I want to do some more measurements tomorrow to see how often a cache like that would hit on various workloads.

Comment 5

[Jan de Mooij [:jandem]]

Fixing the AtomizeString issue in bug 1657559.

Comment 6

[Jan de Mooij [:jandem]]

Denis, would be great if you could confirm bug 1657559 fixes the AtomizeString issue on reddit.

Comment 7

[Denis Palmeiro [:denispal]]

Thanks Jan. This certainly feels better now, I am no longer seeing long 10s+ jank. That being said, it still feels quite a bit slower compared to Chrome. A new profile can be found here: https://share.firefox.dev/31YMmDn. It seems to be possibly just a long GC that is causing the delays, which is understandable considering the amount of garbage scrolling must generate.

Comment 8

[Steve Fink [:sfink] [:s:]]

I don't see any long GCs in that profile. If I filter all markers to just the GCSlice markers, the worst is only 52ms. That one had a budget of 52ms, which presumably is because the browser believed itself to be idle. The budgets may not be right (in fact, I believe in some cases they aren't). But almost nothing goes over budget.

I only see 2 major GCs in that profile, both a bit over 2 seconds long. But that's just the time elapsed between the start and end; the browser is still working for almost all of that time. (The max pauses are 36ms and 52ms.)

Comment 9

[Steve Fink [:sfink] [:s:]]

The most significant GC-related thing is that there are lots of minor GCs. They're 3-4ms each, which is a fair amount of time. At first glance at the memory graph, it looks like it may be a result of lots of steady allocation, but I don't know for sure that there isn't something fixable there.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Olli Pettay [:smaug] from comment #2)

Lots of timeupdate events. Are we possibly dispatching them more often than Chrome?

Nils, you might have missed the needinfo. Mind still checking that?

Comment 11

[Nils Ohlmeier [:drno]]

(In reply to Olli Pettay [:smaug] from comment #2)

Lots of timeupdate events. Are we possibly dispatching them more often than Chrome?

I don't know how often Chrome dispatches them. Firefox appears to dispatch them every 250ms, which is the minimum as per spec if I'm not mistaken: https://searchfox.org/mozilla-central/source/dom/html/HTMLMediaElement.cpp#6783
We don't appear to take current load into consideration as the spec suggest. But since we do the minimum I don't see how we could reduce the load here without breaking the spec.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Looks like timeupdate may get dispatched more often than every 250ms. The task to queue them happens at most every 250ms, but if main thread is busy, there are possibly multiple queued nsAsyncEventRunner objects in the main thread.
So if main thread is busy because of other things, there may be burst of timeupdate events every now an then, and that causes the main thread to be yet more busy - unless I'm missing something.

The spec has text like "if the user agent has not fired a timeupdate event at the element in the past 15 to 250ms and is not still running event handlers for such an event, then the user agent must queue a media element task given the media element to fire an event named timeupdate at the element."
The issue we have is that the time check happens when we queue async event, not when the event actually fires.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Filed bug 1686696 for the timeupdate issue.

Comment 14

[Jason Orendorff [:jorendorff]]

There's not anything left here that JS folks are looking at, so redirecting this to AV.

Comment 15

[Alastor Wu [:alwu]]

We landed some improvement in bug1686696, which is about reducing the frequency of dispatching certain events. Would you mind to help me check if the situation gets improved while browsing Reddit?
Thank you.

Comment 16

[Denis Palmeiro [:denispal]]

I would say it certainly has improved, especially since I first reproduced this 7 months ago. However, we seem to still be quite janky when comparing to chrome while infinitely scrolling on reddit.

Here is a new profile: https://share.firefox.dev/3ucChQA

Comment 17

[Alastor Wu [:alwu]]

Thank you. From the profiled result in comment16, the amount of timeupdate events was indeed significantly less than before, and I noticed that Reddits spent 300~400ms in its event handler, which were mostly called from redditstatic.com. Those operations were done by themselves, which are not related with media, so I'm not sure what we (media team) could do on the improvement.

Maybe we need to move this bug to another component to investigate those non-media-related JS calls to see if we can speed up them or not? Smaug, do you have any ideas?

Thank you.

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

Yeah, I think this bug is rather generic. This does block bug 1689392
We should keep investigating this and others Reddit perf issues.

Comment 19

[Olli Pettay [:smaug][[e-mail]]]

Do you still see this being worse than in Chrome. (Which isn't much, since reddit is pretty bad there too. Checkerboarding all the time a lot. On Linux and Windows.)

Comment 20

[Patricia Lawless]

Moving back to Core::Performance until we figure out who should own it next

Comment 21

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

After all of the fixes made in this bug, I'm not sure what the "poor performance" in Firefox looks like but I did my best to try to reproduce on my high-end macOS dev hardware, comparing a recent Firefox nightly to Chrome. The only significant difference I observed is that when scrolling very quickly with a trackpad, Firefox will display grey content while Chrome almost allows insert the white boxes for each post (caused by checkerboarding?).

However, I wasn't able to reproduce a big difference in the amount of time it took for each page to appear (issue mentioned in comment 1) with either trackpad scrolling or "page down"/"end". And I didn't see any major difference in the amount of time to display the actual content when scrolling (outside of the grey issue mentioned above).

From a user experience perspective, I found Firefox and Chrome fairly comparable and the checkboarding doesn't seem too disruptive so I think this should be taken off the P1 list.

Comment 22

[Benjamin De Kosnik [:bdekoz]]

Removing qf:p1 tag as this is now Priority 3 / Severity 3.

Comment 23

[Bas Schouten (:bas.schouten)]

Denis indicates this bug no longer has actionable info, even if it may not be entirely resolved. Closing.