Slow Searching: Difference between revisions
No edit summary |
No edit summary |
||
| Line 6: | Line 6: | ||
'''Update Feb 2011:''' I'm working on this right now! I've already got startup speed cut in half, and sorting even a very long (80k songs) uncached list takes about 1 second. (cached is instant as usual) Searching comes next!<br> | '''Update Feb 2011:''' I'm working on this right now! I've already got startup speed cut in half, and sorting even a very long (80k songs) uncached list takes about 1 second. (cached is instant as usual) Searching comes next!<br> | ||
'''Up-update May 8 2011:''' Yes, fast search is still being worked on. The delay is that 1) it's hard, 2) it's actually being written by a friend who knows a bunch more about SQL than I do, but his hours are severely restricted, so only a tiny bit gets done each week. But more and more does get done and we're very close. Searching is done now, and they are, as expected, instant. I will be releasing a *very* preliminary version that you must manually opt-into, more notes [[Slow Searching/testing|available here]]. | '''Up-update May 8 2011:''' Yes, fast search is still being worked on. The delay is that 1) it's hard, 2) it's actually being written by a friend who knows a bunch more about SQL than I do, but his hours are severely restricted, so only a tiny bit gets done each week. But more and more does get done and we're very close. Searching is done now, and they are, as expected, instant. I will be releasing a *very* preliminary version that you must manually opt-into, more notes [[Slow Searching/testing|available here]].<br> | ||
'''Up-up-update Jul 2011:''' No, i'm not actively working on it right now, it was taking too long and I felt I need to focus on getting the Windows release completed, and push for the "1.0" version. I may tinker in the background with it but for now it's on the back burner. | |||
<strike>Meanwhile, if you have more than 10,000 songs, i recommend you turn OFF the "update search results as you type" preference.</strike> This feature has been removed because too many people [http://karaoke.kjams.com/forum/viewtopic.php?f=4&t=912 thought it sucked] because they didn't get it. | <strike>Meanwhile, if you have more than 10,000 songs, i recommend you turn OFF the "update search results as you type" preference.</strike> This feature has been removed because too many people [http://karaoke.kjams.com/forum/viewtopic.php?f=4&t=912 thought it sucked] because they didn't get it. | ||
Revision as of 18:25, 31 July 2011
Why is searching and sorting slow?
Well, frankly it's cuz I am not using a super smart database in the back end. You see, when I started this project, i just whipped something together as fast as I could, so I could see results quickly. In hindsight, it would have been worth my time to invest in understanding how to program SQLite, rather than rolling my own. SQL has these blazing fast indexes that make sorting and searching fast enough to update *as you type*, even for a library with 100,000 songs in it. My implementation, however, is only fast enough if you have say 10,000 songs. But even this bogs down when the meta data is not cached, for example the "Label" field is stored only in xml files next to the song files, that data is not stored in the database proper, so when you go to sort by that, kJams must load every single xml file for every song.
So, eventually i'll be removing my old, creaky, written-from-the-seat-of-my-pants database, and replacing it with one based on SQLite. Once that's done, all the data will be in one place, and all those progress bars will just "go away". Keep in mind however that this is a MAJOR re-write of a huge portion of my code, so when i do this it likely will introduce new bugs.
Update Feb 2011: I'm working on this right now! I've already got startup speed cut in half, and sorting even a very long (80k songs) uncached list takes about 1 second. (cached is instant as usual) Searching comes next!
Up-update May 8 2011: Yes, fast search is still being worked on. The delay is that 1) it's hard, 2) it's actually being written by a friend who knows a bunch more about SQL than I do, but his hours are severely restricted, so only a tiny bit gets done each week. But more and more does get done and we're very close. Searching is done now, and they are, as expected, instant. I will be releasing a *very* preliminary version that you must manually opt-into, more notes available here.
Up-up-update Jul 2011: No, i'm not actively working on it right now, it was taking too long and I felt I need to focus on getting the Windows release completed, and push for the "1.0" version. I may tinker in the background with it but for now it's on the back burner.
Meanwhile, if you have more than 10,000 songs, i recommend you turn OFF the "update search results as you type" preference. This feature has been removed because too many people thought it sucked because they didn't get it.
Another thing you can do in the mean time to speed up your searches is to hide any columns you don't want to search. The more columns you have showing, the slower the search will go. To show or hide the search columns, just Context Click in the column header and pick the one you want to show or hide.
Especially slow are the following items (hiding all of them will dramatically speed up searching):
Sub Genre Composer Original Publisher Publisher Rendition Keywords Bio Original Year Language Key BPM
Click here for more info on Searching.