Simple search for "hello" on a Core2 3Ghz machine is over 50x slower:

v0.9.5.2
330 seconds

v0.9.4.5
5 seconds

My database.fpl is about 75MB, indexes around 250,000 music files.

All the music files are on a server accessed via a UNC path.

I tried v0.9.5.1, same results.

It appears the new search options added in v0.9.5.x are making the search of large databases DRAMATICALLY slower.

i noticed the same thing with database search. real slow now.

you got a huge database! i thought i had a lot of music... but 250,000 damn

Been collecting on PC about 12 years now, so it tends to ACCUMULATE

I also noticed that the "Database Search" component from foosion does not suffer from this slowdown, so it is not a bug in the underlying database access code.

I have not experienced this, though my files are located on external disks, spanning 3 volumes and about 150.000 titles.

External, but are they over a network? Maybe that is the keyfactor, network access.

Perhaps the Album List search is now verifying each file's existence before listing it as a match. Not an issue for a local drive with directory caching, but brutal overhead for a network path.

The Album List does not access the network or file system, it only uses the cached data in your media library.

Any idea why the Album List is suddenly so much slower than your Database search component (and the older Album List code)?

No such problem here - tested with a library containing nearly 1TB of music. Which operating system do you use, Windows XP or Vista?

I've tested it on two machines, one with XP SP2, the other with Vista (both 32bit versions). Same results on both.
Both machines are Intel Core2, and have ample memory.

There is no intense disk activity, the CPU shows 100% usage during the search (at least for the Core that FB2K is running on).

That's strange, I tested on Vista 64-bit and XP 64-bit, slowdowns occured only on the XP machine but they weren't as bad as yours.

Does switching Album List views cause massive slowdowns for you as well? If not, I'll change Album List to refresh the entire tree each time the filter expression changes instead of just adding/removing affected items like we do now.

maybe it's a 3rd party component causing this. i had the gapless crossfader installed and it slowed all searches down by an enormous factor. see if you got foo_dsp_crossfader installed

My search speed with Album List is also significantly longer than using the Media Library Search.
Searching for "%play_count% MISSING" takes like 6 seconds in Album List compared to nearly instantly in Media Library Search.
Switching Album List views doesn't cause massive slowdown.
My config is Vista 32bit SP1, foobar 0.9.5.2 with some more official optional components, some 3rd party input components, Columns UI and Lyrics Art.

EDIT: My ML is a little over 20000 songs. Some of you guys have monstrous ML .

This should mostly fix search slowdowns with Album List:
Click to view attachment

Note that Album List's search will never be as fast as Media Library Search because it has much more work to do with building item tree structure.

About Media Library sizes: I don't actually have that much music, I use a user-contributed FPL file with a snapshot of a huge library (155553 tracks) triggering all kinds of worst-case scenarios and bugs.
If you have a comparably big library and don't mind other people seeing your entire library structrure with tags etc, feel free to contribute your database.fpl to our collection.

Not only does it fix it, but it's also about double the speed of v0.9.4.5!!

The "hello" search takes about 2 to 3 seconds now.

Opening the Album List is a bit slower than v0.9.4.5, there seems a second delay, almost like the initial tree fill is happening twice.

The new Album List does some things that cost more resources than their pre-0.9.5 counterparts, such as Windows XP's "natural sorting" for tree items; I don't think it's possible to make startup as fast as before. Faster searching compared to pre-0.9.5 is most likely related to multi-core optimizations of the search engine introduced in 0.9.5.

Would it be possible to have a keystroke interrupt the search? It's always been an annoyance to have long delays between typing a key, and seeing a response on screen. It's particularly a problem with a wireless keyboard/mouse where one is not sure that the keystroke got through.