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

Search on large collections slow. #51

Open
evertvorster opened this issue Oct 7, 2017 · 6 comments
Open

Search on large collections slow. #51

evertvorster opened this issue Oct 7, 2017 · 6 comments

Comments

@evertvorster
Copy link

Hi there.

Firstly, thanks for making this super software, it's really nice.
I have a large music collection with approximately 90000 songs.

When searching for anything in that collection, babe is extremely slow on the first keystrokes, and as the search term gets more specific it speeds up. I am guessing this is because a single character has a really large number of hits, and it takes a minute or two to load the entire list, then only does it insert the next character in the search, and so on.

When I type the text I am looking for in a text editor and cut 'n paste it into the search field, the search is almost instantaneous. (Probably because of the much smaller number of hits)

So, in order to support larger music collections, babe either has to wait until no more text is entered before it starts searching, or monitor keyboard input and abort any current search and start searching with the next input string.

I am using Arch linux, so I can test any fixes quite quickly.
Kind regards,
-Evert-

@milohr
Copy link
Owner

milohr commented Oct 7, 2017

@evertvorster okay, right now i implemented a qtimer, so it will wait 500 milliseconds after the search query has been entered. :)

@evertvorster
Copy link
Author

I'll check in a bit when the repos have synched.
From your description, it appears that babe will now wait for 500ms for new input before starting the search. Its cool, but what if I am a slow typist? Would new input interrupt the previous search?

Thanks for looking into this.
How can I report issues on the KDE phabricator, it must be a pain for you to keep on opening github just to talk to me. Otherwise you can mail me directly at evorster at the usual gmail server.

-Evert-

@milohr
Copy link
Owner

milohr commented Oct 7, 2017

@evertvorster right now i'm listening to the signal textEdited, so yes, if you are a slow typist the search would run and when you edited then i would wait another 500ms and then run the search again.
the solution i see here is to listen to the returnPressed instead, so the search would only run when the return key is pressed.

@evertvorster
Copy link
Author

evertvorster commented Oct 8, 2017 via email

@milohr
Copy link
Owner

milohr commented Oct 10, 2017

@evertvorster that sounds goo. i will try it :)

@geneticdrift
Copy link

@milohr, there's a utility to create a large fake music collection. It might be useful for testing issues like this one during development.
It uses CDDB to randomly tag music files it duplicates from a template.

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