Bug 67237

Summary: search gets really sluggish while typing search string
Product: [Applications] juk Reporter: Juha Kuikka <kuikka-kde>
Component: generalAssignee: Scott Wheeler <wheeler>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Juha Kuikka 2003-11-04 22:54:48 UTC 
Version:           1.95 (2.0 beta 1) (using KDE KDE 3.1.4)
OS:          Linux

I get strange slowdown while typing to the search field in Collection List.

Example, I want to see The Gathering's album 'Mandylion' so I start to type to the search field: 'mand'
at this point I have the following songs in the view as they all have the string 'mand' in them.

file:/home/work/mp3/Blackmore's Night/Ghost Of A Rose (Limited Version)/01 Way To Mandalay.mp3
file:/home/work/mp3/Blackmore's Night/Ghost Of A Rose (Limited Version)/17 Way To Mandalay (Radio Edit).mp3
file:/home/work/mp3/Electric Six - Fire/01-electric_six-dance_commander-esc.mp3
file:/home/work/mp3/Hector/Lap/05 - mandoliinimies.mp3
file:/home/work/mp3/The Gathering/Mandylion/01 - Strange Machines.mp3
file:/home/work/mp3/The Gathering/Mandylion/02 - Eleanor.mp3
file:/home/work/mp3/The Gathering/Mandylion/03 - In motion %231.mp3
file:/home/work/mp3/The Gathering/Mandylion/04 - Leaves.mp3
file:/home/work/mp3/The Gathering/Mandylion/05 - Fear of the Sea.mp3
file:/home/work/mp3/The Gathering/Mandylion/06 - Mandylion.mp3
file:/home/work/mp3/The Gathering/Mandylion/07 - Sand and Mercury.mp3
file:/home/work/mp3/The Gathering/Mandylion/08 - In motion %232.mp3

At this point Juk is quite speedy, when I select one of those songs the yellow cursor-line follows immediately and if I move the window around it is repainted quickly.

Ok, I add the letter 'y' to the search string so it becomes 'mandy'

list is updated to represent those songs that have the 'mandy' in them, namely the Mandylion record. 

Now Juk slows down considerably, repainting the window takes about 2 seconds and when I select one of the songs with the mouse it takes about 2 seconds for the yellow cursor-line to follow.

I can also reproduce this problem with other search strings, for example typing 'metalli' does not slow down but when I add the 'c' to the end it slows down.

I do hope this explanation makes sense. .)
Comment 1 Juha Kuikka 2003-11-04 22:58:14 UTC 
Seems that the bug database did not save my platform's information:
I'm running Debian unstable with Juk from debian package also.

I also forgot to mention that I have ~4400 songs in my Collection list and browsing it (without search) it very fast.
Comment 2 Scott Wheeler 2003-11-05 18:40:08 UTC 
Ok, and you're sure that you're running KDE 3.1.4 not, i.e. 3.1.3?  There was a bug in one of KDE's libraries that I fixed in painting lists that I think wasn't in KDE 3.1.3, but made it into 3.1.4.

Oh, and also what's the CPU on the machine?
Comment 3 Juha Kuikka 2003-11-05 20:31:35 UTC 
Right, It seems there is an error in kde packages in debian. 

Every About dialog tells me that I'm running kde 3.1.4 but packages have mixed version numbers, for example:

kdebase        3.1.3-1
kdelibs-bin    3.1.4-2

So no, I'm not sure what version I have. :)

CPU is 1.2G athlon thunderbird with 1G memory.
Comment 4 Scott Wheeler 2003-11-09 06:25:33 UTC 
Ok, I'll give a description of what the bug was in pre-3.1.4 and we'll see if it fits.  It's a little bit strange, but I'll try to explain.  :-)

Searching gets especially slow when items are far apart.  When you search JuK is just hiding the items that don't match -- they're actually still in the list.

Well, there are some calculations that happen when painting to figure out what the next item is.  Before some of my fixes to the libraries these were very slow; they're much faster now.

So, this problem became the most evident when there was a lot of space between the matched items.  i.e. if when the search is empty these items might normally be separated by 100 or 1000 items or something.

Can you try various sorting combinations to see if this fits?  (Or if it even makes sense?)
Comment 5 Juha Kuikka 2003-11-10 18:00:33 UTC 
It doesn't seem to be this problem.

I tried it by creating some mp3's with the same title name but albums 'aaa' and 'zzzz'. Then I searched for those by title. 

I also compiled the 3.2beta1 kde from sources and it seems the slowdown I initially described is still there but it is not as radical. Juk version seems to be 2.0beta2.
Comment 6 Scott Wheeler 2003-11-26 12:50:38 UTC 
When you add this last key that you mention does it significantly reduce the number of matches?  What column are you sorting by?  (I know these are weird questions, but they're related to some of the kdelibs internals and *might* give me a clue as to what's going on.)
Comment 7 Juha Kuikka 2003-12-05 13:58:09 UTC 
As I reported in my initial raport, there are 12 songs before I add the last key. After that there are 8 songs.

Sorting is by Artist.
Comment 8 Juha Kuikka 2003-12-10 13:21:06 UTC 
I'm glad to report that this sluggishness is gone in Kde 3.2beta2 version of Juk. 
Also JUK's search seems to be much quicker overall.

Great work.
Comment 9 Juha Kuikka 2003-12-10 13:23:46 UTC 
Closing this bug as Juk included in Kde 3.2Beta2 releases does not have this bug anymore.
Comment 10 Scott Wheeler 2003-12-10 13:24:41 UTC 
Ah, great.  This makes me feel better about not being able to find a way to reproduce it.  :-)  (I suspect it was something that I fixed by accident along the way in the process of working on other optimizations.)