Slow Searching: Difference between revisions
No edit summary |
No edit summary |
||
| Line 5: | Line 5: | ||
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". | 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". | ||
Meanwhile, if you have more than 10,000 songs, i recommend you turn OFF the "update search results as you type" preference. | Meanwhile, if you have more than 10,000 songs, i recommend you turn OFF the "update search results as you type" preference. Another thing you can do to speed up your searches is to hide any columns you don't want to search. Especially slow are the following items: | ||
<pre> | |||
Sub Genre | |||
Composer | |||
Original Publisher | |||
Publisher | |||
Rendition | |||
Keywords | |||
Bio | |||
Original Year | |||
Language | |||
Key | |||
BPM | |||
</pre> | |||
Click here for more info on [[Searching]]. | |||
Revision as of 16:16, 6 August 2009
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 "date added" 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".
Meanwhile, if you have more than 10,000 songs, i recommend you turn OFF the "update search results as you type" preference. Another thing you can do to speed up your searches is to hide any columns you don't want to search. Especially slow are the following items:
Sub Genre Composer Original Publisher Publisher Rendition Keywords Bio Original Year Language Key BPM
Click here for more info on Searching.