Saturday, November 15, 2008

Performance improvements...

One of the reasons that I originally wrote ooTunes was because I was very put off with the poor performance of other alternatives.  I tried DOT.Tunes (it was using 10% of my cpu all the time, and resyncing with my iTunes library took minutes).  I tried slimserver and found that in order to keep the slimserver database in sync with my iTunes library I had to run a 1 hour long sync.  I chose to do this during the night, since it bogged down my computer and made playing music from the library skip and buffer.  I spent a lot of time tacking on additional functionality (like marking songs played when I played them, etc.) but it was obnoxious not to be able to see changes to a playlist for as much as 24 hours.  So, ooTunes was born.  I spent a lot of time writing and optimizing the code that reads the iTunes library.  It now is parsed in under 5 seconds, without freezing up my computer, and that's on a library with 14,000 tracks!  This means, what you see through ooTunes is basically what you have in your iTunes library.  If it isn't, reload  the page, and it will be.  


Well, I spent several of the last few days further increasing the pageload speed.  I found that a lot of the time when refreshing the page (usually re-reading the iTunes library is the biggest part of that, though it only re-reads it if there have been changes since the last read), was spent reading online playlist from mp3tunes and pandora.  Many people don't use these so they wouldn't be seeing the slowdown, but for me, it was taking an extra few seconds each time I reloaded.  So I made changes to do a better job caching those as well.  (the demo will now load about twice as fast as it used to, on a fresh login!)


The other area that I've spent (probably too much) time optimizing in the last few days is the load speed on the iPhone or iPod touch.  I found it a bit frustrating on my large library (granted, I also have a not-yet-released feature of my photo library being loaded, which is something like 2000 more playlists to render) but I still thought it could use some speedup.  So I've reduced the image sizes using some cool compression tools that compress images losslessly, and more importantly, I ditched the dependency on Scriptaculous/prototype on the iPhone!  I seriously regret ever having started using Scriptaculous, it brings in something like 60kb (compressed) of javascript libraries for a few tasks (mostly the drag and drop of songs on playlists, etc. in the regular browser)... and there's no fine grained modularity (no way to say, I only want this feature, give me the bare minimum javascript library!)  So, the iPhone interface now loads in about half as much time as it used to (at least on my own library).  There is still a lot of room for improvement, but I'm pleased with the progress that's been made.


I also made some needed changes to the interface on the iPhone.  No longer do you have to tap 10 times to get a song to play (it's still more than anyone would like but I've reduced it as much as I can, tapping a song once now loads the song and one more time on the quicktime play button and it should begin playing).  Radio stations and movies are even better.  One tap and they are playing!   (the reason is that they don't do back to back playlists so they don't require the little play button to be pushed).  I wish apple would give us some REAL javascript controls for the embedded quicktime player, but it doesn't seem to be top on their priorities.  However, it's much better now that I fixed my own problems.  


Now if only I could have made more progress on MooTunes.  It's coming along but my love for "speed optimizing" just overwhelmed my love of making tons of money!


Also, please send me your suggestions and requests for improvements!  I would have probably never made some of these changes if someone wouldn't have spoken out about it!


No comments: