Open Bug 1654087 Opened 2 months ago Updated 20 days ago slow page performance after scrolling through a lot of pages


(Core :: JavaScript Engine, defect)






(Reporter: miketaylr, Unassigned, NeedInfo)



(Whiteboard: [qf:p1:responsiveness])

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

A couple profiles:

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.

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

Flags: needinfo?(drno)
Whiteboard: [qf] → [qf:p1:responsiveness]

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?

Flags: needinfo?(tcampbell)
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Target Milestone: --- → Future

(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.

Flags: needinfo?(tcampbell) → needinfo?(jdemooij)
Depends on: 1657559

Fixing the AtomizeString issue in bug 1657559.

Flags: needinfo?(jdemooij)

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

Flags: needinfo?(dpalmeiro)

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: 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.

Flags: needinfo?(dpalmeiro)

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.)

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.

You need to log in before you can comment on or make changes to this bug.