Testcase generating 50k scrollbars is 36x slower than Chrome
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: mayankleoboy1, Unassigned)
References
Details
Attachments
(2 files)
Open attached testcase
Enter 50000 and press geenrate
15000 elements
nightly: https://share.firefox.dev/4htpdhu (11s)
Chrome: https://share.firefox.dev/4hxoFHi (421ms)
20000 elements
- Nightly: https://share.firefox.dev/4hpW5bv (18s)
- Chrome: https://share.firefox.dev/3WzhPJq (650ms)
25000 elements
- Nightly: https://share.firefox.dev/3Csvgnz (24s)
- Chrome: https://share.firefox.dev/4hvCki3 (800ms)
50000 elements
- Nightly: https://share.firefox.dev/4gg8H3x (78s)
- Chrome: https://share.firefox.dev/4gh8P2q (2s)
|
Reporter | |
Comment 1•20 days ago
|
||
Profile to reload page with 50k elements: https://share.firefox.dev/3CyxvWn
|
|
Reporter | |
Comment 2•20 days ago
|
||
Slightly different testcase.
15k elements:
Generating the page: https://share.firefox.dev/40vNRaf (27s)
Reload page: https://share.firefox.dev/4huXFbE
|
||
Comment 3•20 days ago
|
||
Looking at the first profile, it looks like a lot of Firefox's time is spent setting up and playing the "fade out" effect on overlay scrollbars; so this might not be an apples-to-apples comparison, because your Chrome reference here is using traditional scrollbars which don't have that effect.
Could you test with Firefox set to use traditional scrollbars? (To do that, search your Windows OS settings for "always show scrollbars" and enable that setting.) I would hope you'll see much better results from that.
I think there's also a way to toggle fading overlay scrollbars in Chrome (and/or Edge), but I forget how at the moment (and I'm not on Windows 11 currently).
|
|
Reporter | |
Comment 4•20 days ago
•
|
||
It is working well.
with "always show scrollbars" enabled:
15k : https://share.firefox.dev/3WXKckT (1.1s)
20k: https://share.firefox.dev/4hvDTwr (1.5s)
25k: https://share.firefox.dev/4haymeW (2s)
50k: https://share.firefox.dev/4hpYbbn (5s)
Page reload with 50k: https://share.firefox.dev/4hdMMLE
Testcase2 from comment #2
15K : https://share.firefox.dev/4huJOlz (2s)
|
|
Reporter | |
Updated•20 days ago
|
|
|
||
Updated•20 days ago
|
|
|
||
Comment 5•20 days ago
•
|
||
Thanks; it looks like that puts us more in-line with Chrome's performance on these testcases. (Still a little slower, but not massively so.)
I looked at Comment 4's "50k: https://share.firefox.dev/4hpYbbn (5s)" profile; one thing I'm noticing as potentially-optimizable there is mozilla::DepthOrderedFrameList::Add (as part of mozilla::PresShell::FrameNeedsReflow) -- that spends nearly all of its time in mozilla::DepthOrderedFrameList::Contains, because we've got a massive array there (containing all of the reflow roots, and there's one for each scrollbar).
We could maybe optimize that by switching to use a set-like structure for contains()-checking at some point, but I'm also not sure this is common enough behavior to worry about doing that....
So: I don't think it's worth worrying too much about improvements here, but one last thing that'd be worth investigating is how Chromium (whether Chrome or Edge) fares when configured to use overlay scrollbars, for an apples-to-apples comparison with the Firefox results in comment 0. I think there's some sort of setting or flag to turn that on in Chrome and/or Edge (maybe just Edge?), if you're interested and able to find that.
|
||
Comment 6•20 days ago
|
||
We should avoid firing animation effects for scrollbars anyways tbh. So maybe the overlay animation can be sped up as well.
Description
•