1733227 - Degraded overall Performance (with 2000+ tabs open)

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[quadronom]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

Since v91 I experience an extremly degraded performance of Firefox on my Windows 10 machine.
I had never problems, but meanwhile a lot of my tabs just break.
Where I might seen the "crashed tab" screen maybe once in a month (or even less) formerly, this is now multiple times an hour.

Also in general Firefox became really slow in most regards.
Especially input is always lagging behind. This goes for text input, too, where in JS-intense environments like Whatsapp Web, the typing typically lags behind for a second or two.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Daniel Holbert [:dholbert]]

Thanks for filing a bug to let us know -- sorry to hear about your experience.

This particular point might be actionable:

(In reply to quadronom from comment #0)

Especially input is always lagging behind. This goes for text input, too, where in JS-intense environments like Whatsapp Web, the typing typically lags behind for a second or two.

Could you capture a performance profile using https://profiler.firefox.com/ ? (Click the button there to enable a toolbar-button which lets you capture a performance profile, which then helps show where Firefox is spending its time when it's lagging behind.)

Note that profiles can include screenshots of the page content, which you may not want for WhatsApp Web (for privacy reasons). You can disable the screenshots in the settings for the profiler, and you can also omit them when sharing the profile.

Comment 3

[Sean Feng [:sefeng211]]

Hi, I am going to close this bug since we haven't heard back from you. Please feel free to reopen the bug if you can collect a profile, that'd would be extremely helpful for us.

Comment 4

[quadronom]

Hi, thanks your patience and replying to my report.
I have done making a performance profile. I accidentally (?) used the web dev default setting.
The link is https://share.firefox.dev/3pzXNyl
Hopefully this already does the trick. Otherwise tell me which profiler setting I should use instead.

Comment 5

[Sean Feng [:sefeng211]]

Thanks.

I am able to see some slow event handlers in the profile. Can you try again with the Nightly profile if you have it available, if not can you try again with Native Stacks selected (Go edit settings -> Features -> Native Stack) ?

Comment 6

[Markus Stange [:mstange]]

(In reply to quadronom from comment #0)

Especially input is always lagging behind. This goes for text input, too

In the profile, I cannot find any lagging key input. Do you remember if you were seeing "lagging key input" problems during the recording of this profile?

Comment 7

[quadronom]

Hi, here is another one, not Whatsapp Web but Youtube. https://share.firefox.dev/3zof3tE
It's unbearable, video is only playing the audio without stutter, the visuals are mostly just single frames spanning multiple seconds.

@Markus: Yes, there is a notable input lag while typing. Heck, even right now while typing this there is a lag! And bugzilla has surely less JS then Whatsapp Web. It takes sometimes even seconds for keystrokes to be arriving. One clue might be that they are not lagging in a replicable way, e.g. always 600ms late. Instead there is sometimes no lag at all, and then you go on typing, and it doesn't do anything at all for a while before all the entered keystrokes are in at the same time.

Comment 8

[Markus Stange [:mstange]]

(In reply to quadronom from comment #7)

Hi, here is another one, not Whatsapp Web but Youtube. https://share.firefox.dev/3zof3tE

This is a great profile! It clearly shows two very long instances of jank in the parent process. The time is spent in Styling, Reflow and AnimationInfoEvent sorting, for the main browser window browser.xhtml document.

The reflow spends most of its time in a grid layout inside XUL layout. I'm not sure where we're using grid in the main browser UI.

I think something is accumulating lots of elements somewhere in the UI, maybe hidden from view. Do you have a lot of tabs or a lot of windows open? Do you have an add-on installed that shows many elements in the UI, maybe in a sidebar or a panel? Or do you maybe have some custom CSS applied to the browser?

Comment 9

[quadronom]

lots of tabs
Yeah, guilty. Kind of a tab horder. A couple of hundred tabs are normal. Mostly research.

custom CSS
I use Stylus (the add-on), but that is only cosmetically. I only change colors into dark mode with it. That should not trigger reflowing I think.

Other than that?...

Comment 10

[Daniel Holbert [:dholbert]]

In the profile from comment 7 - 8, the long (1.9s and 1.8s) restyles suggest that entering/exiting fullscreen is the issue there.

Hovering the first one, I see "FullscreenWillChange" in the "First invalidated..." attribution, and "ExitFullscreenInDocTree" for the second one; and the Marker Chart shows long FULLSCREEN_CHANGE_MS markers for those whole jank periods (6.2sec for the first, 7sec for the second).

So it looks like fullscreen operation is causing frontend to restyle itself which causes lots of invalidation, which then takes a while to process. (Probably due in part to the couple-hundred-tabs.)

That's the worst offender in the profile from comment 7, but given that quadronom hasn't mentioned entering/exiting fullscreen so far, I'm wondering if that's tangential to the baseline perf issues that they're seeing.

quadronom, are your issues generally related to moments when Firefox (or e.g. a YouTube video perhaps) enters/exits fullscreen?

Comment 11

[Daniel Holbert [:dholbert]]

I've just filed bug 1751484, specifically on fullscreen operations (e.g. hitting fullscreen button on youtube videos) causing parent-process restyling work that's proportional to the number of tabs (which can be substantial). We can consider that bug as covering the long restyles/reflows that mstange highlighted in comment 8, I think.

So: for this bug here, we should perhaps focus on non-fullscreen issues (assuming quadronom is experiencing general baseline bad-performance that's unrelated to fullscreen operations).

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #10)

quadronom, are your issues generally related to moments when Firefox (or e.g. a YouTube video perhaps) enters/exits fullscreen?

On top of this^, I have one additional question: could you check your actual tab-count, at a time when you're experiencing this issue? (You mentioned "a couple of hundred" but it would be good to confirm that & have a more-precise figure.)

You can find the tab count if you visit about:telemetry and type tab_count into the search box at the top right -- that should give you a result for "Scalars" that's labeled browser.engagement.max_concurrent_tab_count, and that's the number I'm interested in.

Comment 13

[quadronom]

To be honest it is quite normal by now for me that the fullscreen transition is not smooth. The captured jank was especially bad, but yeah, it's similiar most of the time.

When I wrote the report initially I really had trouble with Firefox just crashing out of nowhere very often, which has not happened before. This situation however has now stabilized and I didn't record any crashes so far in 96.x. (The janked transitions are still janky nonetheless)

The other pet peeve was the slow input, which I initially observed in an JS-heavy environment like WhatsApp Web, but actually seemed to happen with every textbox.

Now, I have to admit, there are truly a lot opened tabs here for me. The number is 2176, so yes, that is substantially and for sure affects only few users.

I will see if the aforementioned behaviour is happening again and I will try to make another perf profile.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:boris, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to quadronom from comment #13)

Now, I have to admit, there are truly a lot opened tabs here for me. The number is 2176, so yes, that is substantially and for sure affects only few users

Thanks for checking that. I think this tab-count is likely a big factor in the perf issues that you're seeing, and so fortunately/hopefully that means very few users are affected. I'll classify this as S4 (somewhat reduced-priority) as a result.

I did some tests with 3000 tabs open and can confirm that common operations are somewhat janky (on my fast work ThinkPad; typical user-hardware will be slower).

• Switching tabs: Here's a profile of me switching tabs (by just clicking a tab-title in the tab-strip):
  https://share.firefox.dev/3GrYbUQ
  This takes about 1/2 second, with most of the time spent in FindFloatingViewContaining and FindViewContaining

• Closing a tab: Here's a profile of me closing the rightmost tab (which I had focused and I closed via Ctrl+W):
  https://share.firefox.dev/3HtzMzv
  Again, there's around a half-second of jank, with lots of time in FindFloatingViewContaining

• Un-maximizing my Firefox window was slow:
  https://share.firefox.dev/34I276v
  This incurs a 373ms restyle followed by a 217ms reflow of browser.xhtml, which I assume is due to slight theming/sizing differences between maximized/unmaximized windows, with some relation to the tab positioning and/or sizing (and hence has some amount of work that scales with the number of tabs).

• Fullscreen enter/exit operations are still kinda slow (though less-so) with bug 1751484 fixed.
  Profile: https://share.firefox.dev/3J9cY8K
  As above, we spend a lot of time in FindFloatingViewContaining.

Comment 16

[Daniel Holbert [:dholbert]]

I spun off helper bug 1754052 to specifically cover the question of whether there's anything we can do about all the time we're spending in FindFloatingViewContaining, since that seems to come up a lot in my above-linked profiles of simple operations.

Comment 17

[Timothy Nikkel (:tnikkel)]

Filed bug 1755290 for another thing I noticed while profiling.

I looked at the profile some after bug 1755290 and bug 1754052 and there doesn't seem to be any low hanging fruit using STR from https://bugzilla.mozilla.org/show_bug.cgi?id=1754052#c1, the profiles looks pretty decent giving them a once over look.

Comment 18

[quadronom]

Here I have another (probably interesting) profile for y'all. It has A TON of jank in there.
This time NO fullscreen op! Just being on "dunegames.com".
Scrolling is very janky and the embedded Youtube gameplay trailer is stop motion only :D
https://share.firefox.dev/3GX2RSN

Comment 19

[Daniel Holbert [:dholbert]]

(In reply to quadronom from comment #18)

Here I have another (probably interesting) profile for y'all. It has A TON of jank in there.
This time NO fullscreen op! Just being on "dunegames.com".

Would you mind filing that one as a new bug? I suspect that one has less to do with the massive-tab-count (which is what we settled on as being the core factor in your earlier issues here) -- I'm making that guess in part because your dunegames performance-profile only shows 9 tracks which suggests maybe you didn't have a ton of background tabs open (or they weren't active). Anyway: it would probably benefit from having its own place for discussion/investigation.

(Quick notes: (1) I can't reproduce any substantial jank there, with Nightly on my linux machine -- and (2) looking at your profile, it looks like the YouTube content process is simply not getting any CPU cycles for the periods where it's janking, e.g. during the period shown in https://share.firefox.dev/3JEDTJO . No samples (i.e. "blue bumps") are showing up on that track for most of the jank period). So there may be some contention for CPU time, and our YouTube content-process is losing.

Comment 20

[quadronom]

Okay, I did so over at Bug 1756272.
BTW: It's still the same session with the many tabs open. (But probably indeed not active)

Comment 21

[quadronom]

Another data point. https://share.firefox.dev/3CvW0PR
Not sure if this helps anymore but here you go.
Again being on another site having an embedded youtube video. This seems to bring trouble in general.

Comment 22

[Daniel Holbert [:dholbert]]

(In reply to quadronom from comment #21)

Another data point. https://share.firefox.dev/3CvW0PR
Not sure if this helps anymore but here you go.

Hmm, that profile seems to be 0.05 seconds long, probably not long enough to capture enough information about the issue that you intended to demonstrate.

Could you re-share with a longer section of time to demonstrate the issue that you're aiming to highlight there?

Comment 23

[quadronom]

I have to apologize, that was not intended. Might have zoomed in accidentally before sharing.
Tried to recreate it: https://share.firefox.dev/3MEBWiH

Comment 25

[Wayne Mery (:wsmwk)]

quadronom, do you still experience this issue?

Comment 26

[quadronom]

I'm not on Windows anymore.
Currently it's stable, even with 6k tabs.