-
-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] lag/delay when searching library #61
Comments
Search process is implemented to be run on isolate, when running on isolate, u can only pass simple primitive data types (String, int, double, List, Map etc) this means that when u have an object, u have to convert it first before sending to isolate
I'm going to experiment a little with the workarounds i mentioned tonight also thanks again for the detailed report, it helped me figure out a lot of things |
in my case (2k~ tracks), i don't experience any delay for the text field itself nor the ui, although the search process can take roughly 400ms~ for the first search, afterwards it becomes instant (both scenarios it doesn't affect the main ui thread nor the text field) |
@MSOB7YY maybe you can add debounce timer for onChange. So the search begin only when you stop typing ? |
@fedikhatib yeah that's what i meant by in workaround#2, but it will produce unnecessary delay since the search is mostly instant, except for the first character so i still don't know yet |
okay, few tests showed that its not necessary to run on isolate as for tracks, comparing the search speed (for 836 tracks) showed the following:
|
as stated in the commits, i have pushed the isolate thingy, also it now only searches for enabled chips. |
Just tried the new release and it works great, no more input lag when searching. Thank you! |
that's awesome! glad it's working fine now :> |
+ allow entering yt local search page before resources are prepared ref: #61
When I go to search my library (~ 11k songs using media store), there's some delay (1-2 seconds) between when I type the text, and when the text appears in the search box. Both the text in the search box and the search results appear at the same time, so I think the search operation blocks the text from appearing in the search box until the search is complete. It would be better if these two were decoupled, because with a larger library, you essentially can't see what you're searching for.
Inspecting the code, I think it might be because the onChanged handler for search has to fully run before the text in the search bar is updated, and since that calls searchAll, it takes longer with a larger library.
I can't test it with Namida, but making a small example widget:
I get the same results. The onChanged event has to fully complete before any text shows up in the text field, leading to a 2 second delay. If you want, I can profile it more with a debug build.
The text was updated successfully, but these errors were encountered: