On 8/21/05, Dirk Meyer <[EMAIL PROTECTED]> wrote: > Martijn Voncken wrote:
[snip] > IPC can't be faster than threading because you need to convert > data. But maybe it still works very fast. > I prefer ipc above threading . It is personal but threading is verry tricky. I only use it as a blocking->non blocking IO-wrapper. python has a GIL , and multicore is the future. ipc will scale better on multicore processsors. > I'm no database expert. But when you put everything in one table, > wouldn't it be slow? I mean, album, artist, length, etc. Maybe idea > was that is is faster to do one select to get the basic attributes for > all audio files and after that do individual selects on the attribute > table. Maybe I'm wrong. I guess, one file will have about 20 > attributes. about the structure : it's not pretty or normalized, but a VFS is a differnent beast than a relationlal database. About the speed: Speed is mostly in the index not in the table size. the index is (often) a btree. the speed is mostly related to the quality of the index. but the "insert" speed will suffer a little. further explaining the speed of indexed query's on 1 table: -the performance is often in traversing the index to find the starting point of your select. 2 selects on 2 records is generally slower than 1 select on 20 records. Martijn. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
