GNOME Bugzilla – Bug 540835
Extremely Slow Search Performance
Last modified: 2020-03-17 08:27:57 UTC
I have recent started using Banshee because I find its interface easy to use but I have run into several problems. The largest and most obvious problem is its extremely poor search performance. My collection consists of over 37,000 songs and will take 30 seconds to 1 minute for me to complete my search. 1. The first problem I find with the search feature is its active searching (After the first two character I type, it will freeze up for a period of time to display those results before I can continue my search). In order to search for an artist with a long name, it may take me 5 minutes to complete, and this is an unacceptable behavior. 2. My second compliant is simply the length of time a search takes to complete. When entering a search, the time it takes to return the results can be between 10-30 seconds. This is extremely detouring from the overall program. Should alternative algorithms be used? I previously used Rhythmbox and that had no problem handling the same library. No long search times, no lag while browsing artists/albums. Other information: My Computer: AMD 64 3700+ 2 GB RAM
Just to narrow down the problem (search is generally fast, so I suspect something strange is going on here), can you move/rename your ~/.config/banshee-1/banshee.db (your database)? That will force Banshee to create a new database when you run it again, and you can always move the old copy back if it doesn't help.
I recreated the database as you said, with the same result. Slow search performance. It is especially slow when pausing for a moment in the middle of typing a search because it will search that string. If the time were slightly longer before search, I believe it would make fewer unnecessary searches(which are apparently slow on a large library) and produce faster searches.
I know it's reaching, but could you paste in a word to use as a search term? I wonder myself about the speed at which it starts live-searching, but either way, it really "shouldn't" be that slow. But I guess you knew that. ;)
For example if I do a search for "Matchbox Twenty", it will pause after typing "Ma" for several seconds. Then I will be able to continue typing the next few character, a pause, and so on.
(In reply to comment #3) > I know it's reaching, but could you paste in a word to use as a search term? Does it act as slow if you paste an entire search term in the text box?
When pasting an entire search in the box, It took 3 seconds for the results to appear. This is much faster than typing it in the box by hand but is this really the way a search needs to be preformed?
(In reply to comment #6) > When pasting an entire search in the box, It took 3 seconds for the results to > appear. This is much faster than typing it in the box by hand but is this > really the way a search needs to be preformed? No, I just wanted to compare on your system. Thanks for testing. :) Does it operate faster if you selectively import less tracks? I simply can't reproduce your behavior just because my library isn't that big. :)
I did a test and imported 775 songs. With this number I experienced real search times and a good experience with the search field. It seems the search field is unable to handle large libraries. I also did some googling and found other cases of this: http://osdir.com/ml/gnome.mono.banshee/2006-04/msg00095.html http://www.davehayes.org/2007/11/15/gnome-music-player-roundup http://abock.org/2007/06/27/my-hack-week-the-new-banshee/
(In reply to comment #8) > I did a test and imported 775 songs. With this number I experienced real > search times and a good experience with the search field. It seems the search > field is unable to handle large libraries. Yes, that's what it sounds like. That's unfortunate. > I also did some googling and found > other cases of this: > > http://osdir.com/ml/gnome.mono.banshee/2006-04/msg00095.html > http://www.davehayes.org/2007/11/15/gnome-music-player-roundup These instances won't apply, as these two reports were from the legacy branch (i.e. 0.13.x and before). 1.x was basically a redesign and should be a lot faster. (Doesn't seem to be enough though, judging from your experience.) > http://abock.org/2007/06/27/my-hack-week-the-new-banshee/ This is from the first prototypes of the 1.x series, and definitely shows much faster performance. Something must've gotten in the way between then and now though, because it doesn't sound like you're seeing the kind of performance Aaron highlighted.
Perhaps a delay of say, 2 seconds, before actually starting the search alleviates this problem? (Or does Banshee already do this?)
(In reply to comment #10) > Perhaps a delay of say, 2 seconds, before actually starting the search > alleviates this problem? (Or does Banshee already do this?) Heh, definitely _not_. With a not-huge library (< 8K songs) Banshee searches very quickly and immediately and it's a great user experience. The only bug here as far as I'm concerned is there does still seem to be some blocking of the UI.
Gabriel, it's REALLY slow on my 1400MHz box though ;)
Oh, forgot to add I have ~6500 songs and lots of RAM.
I understand that most people have small collections and this features is favorable for them, but for many others with large collections this behavior is interfering with using the program as a whole. For these reasons I believe it would be a good idea for there be to a setting to turn this behavior off. This way those with large collections or slower computers wouldn't have a problem using the program.
Would it be possible to autodetect this somehow and disable the instant search when necessary? That'd be cool; we're always going to have to account for slow computers. If not, a GConf entry to disable the search would be sufficient IMO; I would think adding this to the Preferences would be overload. Also, Gabriel, what are you testing with? Maybe there is a performance problem here you're not noticing? (I'm not either, but again, my library is small; I still have Banshee 0.99.3 on my desktop and no internet to upgrade it, so I can't test 1.3/SVN.)
Tested on SVN trunk compiled today, with 11,385 tracks in my Music Library and 81 in my Video Library. Searching is as slow as Brad describes, and my computer isn't terribly meager. Blocking of the UI is definitely the most noticeable problem here (i.e. fix that and I probably wouldn't notice) but maybe there are some search optimizations that could be done? Is there any way to use Hyena itself to test queries? (Hmm, I seem to recall a blog post of yours, Gabriel, that discussed it. I'll have to go back and look.)
Hello, I'm expecting same issues on a ~65.000 songs database. Search performance is pretty bad and interface freezes for each key press. A delay before performing the search will enhance user experience. As Andrew Conkling said, ¿is there any way to debug SQL queries?
(In reply to comment #17) > As Andrew Conkling said, ¿is there any way to debug SQL queries? Well, that's not quite what I had said; you can "debug" SQL queries with the `--debug-sql` flag, but that just lists queries that are running in Banshee, whereas I want to "send" Banshee a new query and get the return times.
please do not forget this... it is indeed annoying not blocking the UI while searching is a nice start already :)
*** Bug 610827 has been marked as a duplicate of this bug. ***
This should help a lot: commit fb3c382cbfa943f4dcced1994d46040a9be7e971 Author: Gabriel Burt Date: Tue Mar 2 10:37:20 2010 Improve search responsiveness on large libraries If the library is sufficiently large, add a longer delay before initiating the search so the user can type the whole query out, instead of it initiating the search after each character, and the UI becoming unresponsive (bgo#540835). The exact thresholds for the longer delay are the library has > 20k items or the current, filtered item count is > 10k items.
From experience I can say that the 10000 limit is perhaps a bit high. My library is much smaller, yet I still experience a blocking UI sometimes on my not-that-extremely-ancient machine...
For reference: http://git.gnome.org/browse/banshee/commit/?id=fb3c382cbfa943f4dcced1994d46040a9be7e971
What threshold do you propose? 6000?
I don't have any hard numbers, but that sounds reasonable. Btw, would it be an idea to have the code that handles the SQL query measure the time the query needed? In that case Banshee could start with e.g. the larger 250ms timeout, which could then be adjusted (with small steps) to smaller values when the queries are sufficiently performant to not cause a perceived blocking UI? (Or perhaps I'm just a bit too much into adapting systems... ;))
Ok, I changed it to trigger if > 6k current, filtered items or if > 12k items total
A couple more possible optimization approaches: 1) Change the default search operator to starts-with (currently is 'contains', which I would imagine is quite a bit slower) 2) See if the artist/album comparisons are happening once per track, or only once per artist/album like you'd hope
On my windows box I use mp3toys as my main media player. I believe it uses caches to speed up search. I don't know exactly how it works but I guess that it creates a cache for starting letters of the search (possibly limiting the search space). Also, it makes a distinction between a search for songs and a search for artists. The user has to click a little toggle button next to the search field in order to indicate what type of search is to be performed. Knowing beforehand what type of search the user is performing can also reduce the search space and therefore speedup the search. At least for artist searches. Is it possible to store views of the sql database? In case of artist search one would need a view for the start letter of every artist. In case the artist name consists of multiple words: the artist would appear in multiple views then I guess.
*** Bug 653886 has been marked as a duplicate of this bug. ***
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.