Closed thezeroalpha closed 1 year ago
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
threads
, which is far better than isolates
, unfortunately they dont seem like they will. see https://github.com/dart-lang/language/issues/333TrackExtended
) ~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
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:
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
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.
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 :>
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.