Skip to content
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

Closed
thezeroalpha opened this issue Nov 12, 2023 · 8 comments
Closed

[Bug] lag/delay when searching library #61

thezeroalpha opened this issue Nov 12, 2023 · 8 comments

Comments

@thezeroalpha
Copy link

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:

TextField(
  decoration: const InputDecoration(
    border: OutlineInputBorder(),
    hintText: 'Enter a search term',
  ),
  onChanged: (String x) => {
    sleep(const Duration(seconds: 2)),
  },
)

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.

@MSOB7YY
Copy link
Member

MSOB7YY commented Nov 12, 2023

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

  • solution:

  • some workarounds:

    • prevent searching when there is only 1 char in text field, this may help a lot but not always
    • add a small delay (200~500ms) before starting search, to give time to text field to update first (this might be not efficient, considering when u are typing fast)
    • the serialization/deserialization mainly done for tracks (TrackExtended) and playlists (GeneralPlaylist<TrackWithDate>), to be able to access information like artists, genres, album, year, etc (check Track Search Filters in extra settings), or moods, comment, tags as for playlists
  • the delay u see (1~2 seconds) would be doubled if not on isolate

  • the sleep() function in the example u sent is supposed to block the main thread, so it's not related to how TextField.onChanged behaves, yet it demonstrate what happens in Namida.

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

@MSOB7YY
Copy link
Member

MSOB7YY commented Nov 12, 2023

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)

@fedikhatib
Copy link

@MSOB7YY maybe you can add debounce timer for onChange. So the search begin only when you stop typing ?

@MSOB7YY
Copy link
Member

MSOB7YY commented Nov 12, 2023

@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

@MSOB7YY
Copy link
Member

MSOB7YY commented Nov 13, 2023

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:

  • using isolate (current behavior):

    • 0.270721s
    • 0.047743s
    • 0.064194s
    • 0.036904s
  • without using:

    • 0.003284s
    • 0.001786s
    • 0.001229s
    • and even lower
  • as noticed, there is a speed improvement by 25x~, gonna see if workaround#2 is necessary and then commit

@MSOB7YY
Copy link
Member

MSOB7YY commented Nov 13, 2023

as stated in the commits, i have pushed the isolate thingy, also it now only searches for enabled chips.
the delay (200ms) is also implemented, just for steady look/feel when fast typing.
closing as fixed (i hope), let me know the next release.

@MSOB7YY MSOB7YY closed this as completed Nov 13, 2023
@thezeroalpha
Copy link
Author

Just tried the new release and it works great, no more input lag when searching. Thank you!

@MSOB7YY
Copy link
Member

MSOB7YY commented Dec 5, 2023

that's awesome! glad it's working fine now :>

MSOB7YY added a commit that referenced this issue Jan 1, 2024
+ allow entering yt local search page before resources are prepared
ref: #61
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants