You are here: Home » Topic » performance differences between itunes and nslu2page 2

performance differences between itunes and nslu2

Viewing 4 posts - 16 through 19 (of 19 total)
  • Author
  • #9184

    @CCRDude wrote:

    @ron: well, I’ll try to disable smart playlists when the machine isn’t used for some time and I find the sqlite terms to rename the playlists table to something else temporarily, so I don’t have to enter them all again afterwards 😉
    If that is the case, it seems iTunes is coded even worse than I could imagine 😀 The protocol at least allows to read playlists separately, but may be right, they’re there immediately in the client once opened, might be iTunes is reading their contents on connection directly as well.

    Right, it sucks *everything* down on the connect. Until I get a gdbm backed db, though, it will be hard to tell where the bottleneck is. Might be that indexed reads into the database is fast enough that I could build a small btree in memory just with sizes, and stream it all out on a pass through the tree. That way, I’m building it in memory, and get rid of a pass on the db.

    Dunno… might play with the memory map too, just to see how it shakes out. I just gotta finish up the vista crap first. Ugh.


    Hmmmm… I get more confused by the day 😀

    I’ll repeat my previous results and add one more:

    With svn-1498 & sqlite3, accessing 20k songs & 10 smart playlists took 1:42.
    With svn-1498 & sqlite3, accessing 20k songs & no smart playlists took 0:47.
    With 0.2.4 & gdbm, accessing 20k songs with ??? took 0:28.

    I guess I’ll have to check with 0.2.4 again to make sure whether that was with playlists or not; looking at those times now, if 0.2.4 was without smart playlists, the sqlite3 loss may only be 50% instead of 350% 🙂
    In that case, the smart playlists would be at fault. I’ve been thinking on how this situation could be improved… do you make additional passes for those (probably)? In that case the file caching method would probably be tuned even finer… though I start to tend thinking that using the smart playlist criteria on all those songs ten times might also be the factor, which couldn’t be influenced really.

    Need to get used to using a Soundbridge in the office as well I gues… 😀


    Well smart playlists are a pain in the performance-neck, deffo.

    They are really “smart” though. That is they are created in realtime for every query. TO buffer them would greatly improve performance. I rencelty played a lil with smart playlists aka “all except 2-7 dirs”, which came down awkward, performance-wise.

    A list with all the song IDs should suffice, shouldn’t it? 😉


    Hmmm right…

    * another table (ouch *g*), simple songid-playlistid.
    * updating this table (add & remove) whenever a smart playlist is changed.
    * updating this table (add) when the scan finds new songs.

    Hmmm sorry… thinking too much in databases recently… just have a separate file named playlist.cache in the cache folder and put each song id as an unsigned long in there and thats it, even with 20k songs, that would not mean too much in memory while using it as a help in processing.

Viewing 4 posts - 16 through 19 (of 19 total)
  • The forum ‘General Discussion’ is closed to new topics and replies.