1384733 - [meta] "List all tabs" dropdown list is slow with many tabs (~750), takes 2-3 seconds to show

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect, P5)

Description

[nivtwig]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170726030207

Steps to reproduce:

I am browsing with ~750 tabs after starting Firefox (so except for 1 tab, all of them should be unloaded), and clicking the "List all tabs" toolbar button.


Actual results:

The tabs list dropdown takes 2-3 seconds to show which is slow and annoying.


Expected results:

The tabs list dropdown should show immediately

Comment 1

[nivtwig]

I think this bug blocks Bug 1338595 ( UIJank ) , and should be added to its dependency list, I also added a comment there :
https://bugzilla.mozilla.org/show_bug.cgi?id=1338595#c2

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Would you be willing to gather a profile for us? Instructions are here: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem

Comment 3

[nivtwig]

Yes, my profile is here:
https://perfht.ml/2u7tVtf

Comment 4

[nivtwig]

I submitted a profile, can someone check the bug report and change the status to "NEW" (confirm it) ?

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Hey nigtwig,

Thanks for the profile. My apologies for not getting back to you sooner - vacation occurred.

The two things that stand out from this profile for me are:

1) The ~237ms worth of samples spent in _createTabMenuItem: https://perfht.ml/2hGmdFk . It's possible we could reduce this by using a document fragment instead.

2) The ~741ms worth of samples spent flushing layout synchronously: https://perfht.ml/2hGpsfW . This happens on the popupshowing event here: http://searchfox.org/mozilla-central/rev/bd39b6170f04afeefc751a23bb04e18bbd10352b/toolkit/content/widgets/popup.xml#271-287 - specifically, when getting the width of a shortcut entry. We might be able to work around that using some good ol' CSS instead of script, but it would require some investigation.

I don't personally think this should be part of the 57 MVP, but this is great stuff for follow-up work, or perhaps mentored work.

I'll file bugs for these two findings shortly.

Comment 6

[Florian Quèze [:florian]]

(In reply to Mike Conley (:mconley) from comment #5)

> 2) The ~741ms worth of samples spent flushing layout synchronously:
> https://perfht.ml/2hGpsfW . This happens on the popupshowing event here:
> http://searchfox.org/mozilla-central/rev/
> bd39b6170f04afeefc751a23bb04e18bbd10352b/toolkit/content/widgets/popup.
> xml#271-287 - specifically, when getting the width of a shortcut entry. We
> might be able to work around that using some good ol' CSS instead of script,
> but it would require some investigation.

We could also special case the situation where we have only one item with a shortcut in the whole menu. That would help for the all-tabs, the Window and the Help menus. But I wonder if this issue also exists for the Bookmarks menu (where there's more than one shortcut).

Comment 7

[(no longer active)]

Not sure if anyone spotted this issue in the profile, but there is an underlying widget issue here: GetThemeMargins() is *super* expensive: http://bit.ly/2wsAKL8

I filed bug 1393685 for it.

Comment 8

[nivtwig]

The bug status should be changed to confirmed (NEW) : I submitted a profile and several problems were found.

Comment 9

[nivtwig]

Since bug 1388504 was resolved as duplicate, added dependency on bug 1356765, its duplicate.

Comment 10

[:Gijs (he/him)]

All the issues here are tracked in deps, so marking as meta and clearing priority.

Comment 11

[:Gijs (he/him)]

Emilio just did a bunch of work to enable lazy (as opposed to eager, which we've had ~forever) frame construction for XUL in bug 1584935, in part because I saw the frame construction making a difference when I profiled some of the slowness here. I need to verify that we're seeing a positive impact from that, and doublecheck what's left. I have some ideas on how to make this faster still.

Though, as I'm writing thoughts down here anyway: part of me also wonders if there's some way of doing this that doesn't involve actually adding all the DOM nodes. I don't really think a menu with 6000 (cf bug 1634172) items (or really, anything over about 50-100) is actually usable. Perhaps we should only show the visible tabstrip in full, and add a search field into the menu to filter by to find other tabs, or something. Though then again, you can already do this from the address bar...

Comment 12

[:Gijs (he/him)]

As expected, this is significantly better. I filed bug 1639925 for some more optimizations (that'll benefit this case but also other toolbarbutton-using tasks).

Comment 13

[reikred]

I would like to add two observations (using firefox 76.0.1 as test case):

1. list-all-tabs (v widget) can be fast in a freshly started firefox, even with almost 4000 tabs. Both initial presentation of list and scrolling will be fast.

2. list-all-tabs SCROLL performance can be VERY slow after firefox has been running for hours or days, even if the initial presentation of list-all-tabs is still quite fast.

Comment 14

[:Gijs (he/him)]

(In reply to reikred from comment #13)

2. list-all-tabs SCROLL performance can be VERY slow after firefox has been running for hours or days, even if the initial presentation of list-all-tabs is still quite fast.

This seems like a separate issue. Please file a separate bug and include a profile from the Firefox profiler that shows the slowness.

Comment 15

[reikred]

(In reply to :Gijs (he/him) from comment #14)

(In reply to reikred from comment #13)

2. list-all-tabs SCROLL performance can be VERY slow after firefox has been running for hours or days, even if the initial presentation of list-all-tabs is still quite fast.

This seems like a separate issue. Please file a separate bug and include a profile from the Firefox profiler that shows the slowness.

I'll start by posting the requested profile here. If you think this problem is unrelated, I can create a separate bug. I'm not skilled at interpreting firefox profiles, so please take a look.

Here it is: https://perfht.ml/3eifzxp

Comment 16

[:Gijs (he/him)]

(In reply to reikred from comment #15)

(In reply to :Gijs (he/him) from comment #14)

(In reply to reikred from comment #13)

2. list-all-tabs SCROLL performance can be VERY slow after firefox has been running for hours or days, even if the initial presentation of list-all-tabs is still quite fast.

This seems like a separate issue. Please file a separate bug and include a profile from the Firefox profiler that shows the slowness.

I'll start by posting the requested profile here. If you think this problem is unrelated, I can create a separate bug. I'm not skilled at interpreting firefox profiles, so please take a look.

Here it is: https://perfht.ml/3eifzxp

Thanks! Yes, this is a separate bug. We get stuck for actual seconds in trying to get information out of X11 (via nsIFrame::GetScreenRectInAppUnits). Please file a new bug and clarify what kind of setup you're seeing this on (wayland, x11, one of those pretending to be the other, what desktop env, distro, etc.). It would also be useful if you could clarify what kind of jank you're seeing (like, is it "just" dropped frames, or does painting happen quickly but it seems like scroll events are not being processed, or something else), and how you're scrolling (mousewheel, keyboard, something else)

Comment 17

[reikred]

It appears to me that the bug has gotten fixed as a byproduct of some other code changes. I no longer experience that "List all tabs" dropdown list is slow with many tabs. I think it is ok to close this bug now.

Comment 18

[:Gijs (he/him)]

bug 1356765 was about menus, but we use a panel now, and for the panel bug 1666497 was a recent fix that may have helped a bit here.

I'll close this, though comment #16 would suggest that the last issues reikred saw were more of a widget issue - if people are still seeing significant slowness here, please comment, ideally with a profile from the firefox profiler (see https://profiler.firefox.com/ ) that shows the slowness.