I've had slow performance with my ipod (about 15,000 mp3s). I've traced this back to the use of g_list in the SortTab code. The g_list routines do not handle appending to end of list rapidly (entire list must be traversed), and the overhead of keeping the g_list in in sync with the hash slows things down much more. With original 0.99.14 code it took 160 seconds to load, and change sort selections 3 times.
This patch implements the list directly in the TabEntry structure so hash and list can be kept in sync fast with searching the list. It also uses a doubly linked list implementation that can append to end of list in O(0) time.
I would have patch current SVN, but this is currently not working for me. Please add this patch into main code. Email if you have questions or comments. Thanks.
Patch to speed up Sort Tab operations
I forgot to mention new code takes 16 seconds to do same load and change sort selection 3 times.
Applied your patch to Ubuntu's gtkpod-aac 0.99.14 using libgpod 0.7.0 and here are the results:
2299 Tracks on Main playlist (iPod selected)
iTunesDB backup stored in my ~/.gtkpod directory
2m46s to change left sort tab to genre
3m0s to change it back to artist
1m25s to change playlist from main to Podcast (205 tracks)
No change, and maybe worse than before.
I will checkout the trunk version and see if I get better results.
Tried trunk (gtkpod 0.99.15SVN libgpod 0.7.3SVN - did not apply patch)...initially loaded Podcast playlist in about 5 seconds, clicked on the main iPod playlist and it used 100% cpu for over 10 minutes, killed it.
I guess I'll have to wait for this to become part of a stable release. Until then, gtkpod is un-usable for me.
The patch was primarily intended to speed up change of selections within a category (i.e. one artist to another artist). I have not looked at why things are so slow changing categories. For me this is even slower than changing items within a category; however, I've not looked into why, as I almost never change categories. Thanks for trying it though.
-Rad