1820171 - "List all tabs" dropdown still slow with lots of tabs

Status: NEW

(Firefox :: Tabbed Browser, enhancement, P3)

Description

[Oriol Brufau [:Oriol]]

Bug 1384733 improved the performance of "List all tabs" quite a bit, but I still think it's too slow. For 6666 tabs, showSubView is taking about 700ms to complete, which is annoying when I accidentally the button to show the dropdown.

Most time seems to be spent on _setRowAttributes or _createRow in general.

It seems to me this could be optimized by doing something similar to about:downloads, which makes all entries be dummy empty rows, and then only updates the visible ones when scrolling or such.

See https://searchfox.org/mozilla-central/rev/dcf64fc565e3749119bd57202e2ab06533155d16/browser/components/downloads/content/allDownloadsView.js#287-296

Comment 1

[Oriol Brufau [:Oriol]]

Rather than doing it manually like about:downloads, I think that once content-visibility: auto is completed, just updating the rows on contentvisibilityautostatechange would probably be much simpler.
https://drafts.csswg.org/css-contain-2/#content-visibility-auto-state-change

Comment 2

[:Gijs (he/him)]

Here too a performance profile from current nightly would be really helpful.

(In reply to Oriol Brufau [:Oriol] from comment #1)

Rather than doing it manually like about:downloads, I think that once content-visibility: auto is completed, just updating the rows on contentvisibilityautostatechange would probably be much simpler.
https://drafts.csswg.org/css-contain-2/#content-visibility-auto-state-change

It looks like per bug 1820058 this was only recently enabled on Nightly, and I guess per the regressions marked on that bug we're not yet ready to ship. :dholbert, do you know what the timeline is for shipping content-visibility: auto?

Comment 3

[Daniel Holbert [:dholbert]]

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

:dholbert, do you know what the timeline is for shipping content-visibility: auto?

Possibly in the 116 timeframe? There are some bugs that need fixing, hooked off of metabug 1660384.

Though I think it's probably stable enough to turn on for frontend code already. So if someone were to prototype a fix for this bug here that depended on content-visibility, I'm sure we could land a trivial patch to have it enabled in frontend code beyond Nightly, in support of the patch here.

Comment 4

[:Gijs (he/him)]

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

Here too a performance profile from current nightly would be really helpful.

Oriol, are you able to help with this?

Comment 5

[Cieara Meador [:cmkm]]

We should coordinate with the Reusable Components team to implement a virtual list pattern in the Tab Manager. There is an official Lit library here which may make this easier. The Thunderbird team has some prior art we can also reference, in the form of the Tree View code.

Some potential snags:

• Lit and XUL may not cooperate nicely in some situations.
• Some work may need to be done to make Fluent performance in Lit better.

Comment 6

[Julien Wajsberg [:julienw]]

Here is a profile on my computer for this issue: https://share.firefox.dev/4a3ipTr

Opening the dropdown is very slow (esp lots of image decoding for favicons, maybe this could be made lazy even without a virtual list?).

Also it visibly scrolls down after being displayed (in the profile especially there is a restyle triggered by removing an attribute?).

Closing is also visible in the profile as well (~750ms while profiling) with what looks like lots of useless work: saving the session, restyling for something that will be removed; and finally another restyle. But as a user this disappears right away, so I think this isn't as bad as the opening task.

Comment 7

[:Gijs (he/him)]

(In reply to Julien Wajsberg [:julienw] from comment #6)

Here is a profile on my computer for this issue: https://share.firefox.dev/4a3ipTr

How many tabs are open in this window?

Comment 8

[Julien Wajsberg [:julienw]]

Looks like there are 5249 of them 😳

Comment 9

[Timothy Nikkel (:tnikkel)]

(In reply to Julien Wajsberg [:julienw] from comment #6)

Here is a profile on my computer for this issue: https://share.firefox.dev/4a3ipTr

Opening the dropdown is very slow (esp lots of image decoding for favicons, maybe this could be made lazy even without a virtual list?).

I see time spent loading images. This is because the images are displayed using a xul image, so the loading of the image happens during frame construction. Switching to html img would likely make this more async as that does not load its image during frame construction.

About half of the time is spend checking the preload service if we have preloaded this image, just taking the hash of the uri is most of it (the uris are relatively long since they are data uris). XUL images also aren't preloaded, unless they are specified in a link or preload element, so this is likely useless work.

Also the preload service uses a hashtable key that is very similar to the hashtable key that the imgLoader uses. If we could unify them we would save doing that hashing work twice, and would be a win on every image load.

Comment 10

[Kestrel]

The icon on bugzilla.mozilla.org seems to be particularly slow (noticed in Bug 1923363 Comment 10) with 200 tabs producing 1000ms jank in a clean profile (https://share.firefox.dev/3Ajaupn). In comparison, the same number of tabs for mozilla.org produce 300ms and wikipedia.org produce 200ms jank.

The icon that seems to contribute to perf issues:
https://bugzilla.mozilla.org/extensions/BMO/web/images/favicon.ico
X-ICON Image, 136.92 KB, 128px × 128px, 7 image sizes.

Comment 11

[Timothy Nikkel (:tnikkel)]

(In reply to Kestrel from comment #10)

The icon on bugzilla.mozilla.org seems to be particularly slow (noticed in Bug 1923363 Comment 10) with 200 tabs producing 1000ms jank in a clean profile (https://share.firefox.dev/3Ajaupn). In comparison, the same number of tabs for mozilla.org produce 300ms and wikipedia.org produce 200ms jank.

Based on comment 9, a lot of time is spent hashing a data uri representation of the icon, so if the data uri is larger, it would take more time.