Skip to main content
Topic: Change Request: Performance "Trick" on very large Libraries (Read 962 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Change Request: Performance "Trick" on very large Libraries

Hi,

if you use foobar with very large libraries, the search becomes very slow.

If this could not be speed up, then at least the input should be non-blocking while searching after entering each letter.
Means if i type abcde actually it hangs after a, b, c, d and finally e.

What i prefer: The input textbox should react in realtime without noticed delay, so it does not feel that laggy, even if the list ist still being searched.

Change Request: Performance "Trick" on very large Libraries

Reply #1
Hi,

if you use foobar with very large libraries, the search becomes very slow.

If this could not be speed up, then at least the input should be non-blocking while searching after entering each letter.
Means if i type abcde actually it hangs after a, b, c, d and finally e.

What i prefer: The input textbox should react in realtime without noticed delay, so it does not feel that laggy, even if the list ist still being searched.

How big is this library?

Change Request: Performance "Trick" on very large Libraries

Reply #2
if you use foobar with very large libraries, the search becomes very slow.
If this could not be speed up, then at least the input should be non-blocking while searching after entering each letter...

What i prefer: The input textbox should react in realtime without noticed delay...


Advice: you should use Facets. No delay when typing a letter. Typing of two or more letters possible. (I use it with a very large library)

Where do you use an input textbox?

Change Request: Performance "Trick" on very large Libraries

Reply #3
I reference to the standard search box in foobar2000 "Media library search".

Change Request: Performance "Trick" on very large Libraries

Reply #4
I reference to the standard search box in foobar2000 "Media library search".

How large is this library, I consider myself to have a big library and don't have the problems you describe.

Change Request: Performance "Trick" on very large Libraries

Reply #5
about 120.000 files, over 600 gb, over 8000 folders.

Change Request: Performance "Trick" on very large Libraries

Reply #6
I use quick search toolbar with a much larger library and the searchresults appear instant (<20ms).
my library index resides on a ssd

Change Request: Performance "Trick" on very large Libraries

Reply #7
I use quick search toolbar with a much larger library and the searchresults appear instant (<20ms).
Yes, because quick search toolbar only searches after submitting the query string not after every key stroke. And your library is probably also quite small.
my library index resides on a ssd
This doesn't matter for the search as the library will be completely loaded to memory on foobar2000 startup.

Change Request: Performance "Trick" on very large Libraries

Reply #8
I can second that a small delay before the search actually fires would be welcome. The default search definitely gets pretty rough with a sizable library, with small freezes after each letter input. It gets better once there are less tracks returned due a longer, more specific search string.

One of the reasons I've been using the quicksearch component most of the time (although not the only) is the fact that you can adjust the delay.

Change Request: Performance "Trick" on very large Libraries

Reply #9
Yes, because quick search toolbar only searches after submitting the query string not after every key stroke. And your library is probably also quite small.

quicksearch toolbar also has this "autosearch" feature, with configurable delay when it will start searching

This doesn't matter for the search as the library will be completely loaded to memory on foobar2000 startup.

thanks for clearing that up, did not know

Change Request: Performance "Trick" on very large Libraries

Reply #10
ok a start delay would be another solution. but removing the delay from the input field (seperate thread/process) would be much more smooth if you do some "interactive" search while adding and removing letters.

like trying: Joe, Bannana then removing back to Joe, Banana it the old behaviour (no delay) should be kept. just the gui smoothness should be changed by some multithreading stuff... (the delegate... thing)

adding a delay after each letter which has to finish until the search occurs would drive me more mad (more than current behaviour) ;-)

 

Re: Change Request: Performance "Trick" on very large Libraries

Reply #11
to make it more clear what i thought:
you should use multiple processes/tasks/childs for library and playback.
so the player core will never stop playing if library is under heavy load and consuming the cpu power/time.

 
SimplePortal 1.0.0 RC1 © 2008-2020