Testing gnome (and gmpc) on slow hardware
Looking around the house at what low-end hardware I have I could install linux (and gmpc) on withouth much hassle, I came across an old iMac I got 1/2 back:
This are the specs:
iMac First generation (blue and white)
clock : 233MHz
revision : 2.2 (pvr 0008 0202)
It is probly upgraded, but it’s still a low-end system.
I’ve installed debian on it (testing), and after 1 hour I nicely looked at a gdm login screen.
typing in my username/password I expected not much, but gnome loaded pretty fast (I couldn’t get a another cup of coffee in between) and the desktop is responsive, and also programs like nautilus and gnome-terminal are fast enough to be usefull. Epiphany and thunderbird start time is on the long side, but once running you don’t realy notice it being low-end.
But back to installing gmpc, the reason I installed it in the first place.
I first installed gmpc that comes with debian (0.12), it actually ran faster then I expected it be, but it is slow loading/displaying the playlist.
gmpc from svn, is an improvement, esp on lists bigger then 10k songs. The biggest “visible” difference is the time it takes to make the playlist directly usefull.
One other things I noticed that I didn’t realy looked for, was the memory usage. It looks like the custom tree model saves alot of memory. The new gmpc (on completely synced playlist) uses 20% less memory, and has more information availible for every song then the old one did. (The old one only had a formatted string, while the new one has every id3 data field availible,). If people want, it would be relatively easy to have only the currently visible songs availible and save alot of memory there, but this is something that is going to cost you alot of bandwidth and probly cpu @ mpd’s side.
Thinking about how mpd works, and how plchanges work, I think I can limit alot of transferred data by some “inside” knowlege on gmpc’s part.
So f.e. when initially downloading a playlist, I now request a list of song position (we know this allready because it’s just the row number/array index) and id. This is kinda useless, because I can just allocate an array of playlist-lenght (this is something I can easily query), if I need to find fetch the data from mpd all I need to know is the position, and that is something I know. So I can create the initial playlist with by just requesting the lenght.
When changes ocure, I just need the position of the first song that changed, after that song (knowing the total lenght), I could just clear all entries, and resize the array. This sound inefficient, because you need to refetch all the songs after the changed song, but this is something plchanges in it’s current state also forces me todo.
I will need to add just one command to mpd to make this happen (the id of the first changed song).
Problem is that this optimalisation will only work on a “patched” mpd, and it might be even a bit slower on a not-patched mpd. (I doubt it will be much, because the loading of the dat in the tree is improved, and now happens in idle time, so gmpc will allready responsive when doing it.).
I’ll blog about what I will do, one thing I wonder, if I don’t have my “extra command” availible on mpd, what would be faster (in user experience), doing an update the “old” style, or just resync the whole playlist “new-style” (average offcource, deleteing the last song will always be slower “new-style” and deleting the first will always be faster “new-style”).