Closed heikomat closed 1 week ago
Oh, and i just noticed, when switching back to version 2.7.2, which we currently use in production, i cannot find these blocking "recalculate style
-parts during initialization" in my profilings at all.
Update: Found them, but they are in another place in the profiling. They also seem to be way faster. They seem to all affect 0 elements, while the blocking parts in the original post affect ~1300 elements (in my tests, probably depends on the number of children in the ScrollContainer)
good day @heikomat :)
I see.. short explanation why this selector is needed and what it does:
OverlayScrollbars
to an element which has a non-default scroll direction. Examples for this are direction: rtl
, flex-direction: column-reverse
, flex-direction: row-reverse
and any writing-mode
values which are not horizontal-tb
. Those can also be combined, for example an element with the style direction: rtl; flex-direction:row-reverse
will end up with a default scroll direction because those two "cancel out" so to say.As you probably already figured out, this doesn't really affect the functionality of your app, because you're probably only using the default scroll direction. Because the coordinates will always fallback to the default scroll direction your app will also continue to work even without the style. So for you this whole detection brings 0 benefit and only makes the update cycle slower.
This detection is already cached and optimized in how many times it runs, but is must always run at least once (thats why you mostly will only feel the performance impatc on the initialization) or when updating with update(true)
I'm having a few ideas of how to improve this:
Do you have any thoughts or preferences of how to solve this problem?
An option to hint the scroll-direction would definitely work for me and sounds like a simple enough solution.
Only thing i find strange is, that the problem doesn't seem to exist in 2.7? or maybe i'm just not seeing it in the profiling.
@heikomat that make sense since this feature with the non-default scroll-direction was added in v2.8.0
..
I still need to think about this a little bit, since a separate option could be hard to explain / discover for not experienced users.. this problem should be fixed in the next release though
I understand. Take your time and thanks a lot! :)
@heikomat I've just released v2.9.2
which includes a fix for this issue. You don't have to do anything in order of this optimization to work. I'm now checking whether its likely that the scroll element has a non-default scroll direction and if not the measuring code is not executed.
Please try it out and give feedback :)
@KingSora thanks! It might take a couple days before i can test that. Expect a response within the next week :)
Whatever you did seems to have helped :) version 2.9.2 is now slightly faster than 2.7.2, while 2.9.1 was measurably slower.
I conducted all the following tests under the following conditions:
In my tests, i navigate within a single-page-application to a page that renders a container with defered OverlayScrollbars and elements inside. There seems to be two scrollbars initializing, but that doesn't matter to much, as the results remain comparable. The measured time is from the first "Task" that contains OverlayScrollbars-logic until all work is done (as can be seen in the screenshots)
I did two runs for the versions 2.7.2, 2.9.1 and 2.9.2. Here are the results:
As you can see, in my specific test-setup, version 2.9.2 uses measurably less time for scripting compared to 2.7.2 while requiring about the same amount of rendering. 2.9.1 is the worst of the three, requiring as much scripting as 2.7.2 and nearly double the rendering time.
In my tests, initializing an OverlayScrollbars still takes some time (~70ms) but that might very well be an issue with the elements i'm rendering in there and not with OverlayScrollbars. Just for reference, Here is a zoom-in of the last "Task" of the last 2.9.2-measurement:
These tests and writeups take time, but if it helps you with this Project it's well worth it. Thank you for fixing this, and making it the fastest version i've tested :)
Closing this issue as i consider it solved
@heikomat I really appreciate the work you put into the tests and comparisons between versions. It really helps me to improve the quality / performance of the plugin.
I'm glad the new version solved this specific issue.
Please feel free to open as many bug / improvement issues as you want, I'll try to follow up on every single one :)
Describe the bug In my react application, i have some OverlayScrollbars. It seems like this selector (only the one with
> *
) about doubles the time it takes to initialize the scrollbars: https://github.com/KingSora/OverlayScrollbars/blob/d33ea868ce9800f051f00a8015df67e4b3ae3f8e/packages/overlayscrollbars/src/styles/structure.scss#L145I noticed that this selector was checked a lot, but never actually matched (in my case) when trying out chromes new
enable css selector stats
-optionTo Reproduce
Expected behavior I would like the scrollbar initialization to be as fast as possible
Examples I'm currently at work and don't have time to create a working sandbox. Sorry :( I hope the info i collected is sufficient
Environment