4 GiB? Try 6.

One of the luxuries of having a whopping 6 GiB of RAM is the luxury to run lots of apps at once. Look ma, media players:

I confess I’m not sure where certain figures are coming from regarding RAM consumption on media player apps. It’s clear that RhythmBox is pretty lean RAMwise with a library the size of mine, but for all other players, there seems to be some pretty consistent comparative values that can be reached. What I wasn’t expecting was how high Songbird’s CPU consumption would be – I thought its resource gobbling was mostly limited to RAM and disk (as all these players use Gstreamer for playback). Certainly there’s no basis for statements like “3-10x more memory than RB” for ANY player, bugs aside. And bugs should be filed so they can be fixed.

Edit: I had a request for a non-jpg representation of the figures. Here it is. It’s the same file in all cases (an AAC or an Ogg, I don’t remember which), and before anyone asks, I had no apps open other than the players, Evolution, and X-Chat. Someone else suggested I should stop giving the misleading VIRT value from Top, so have re-measured the numbers using gnome-system-monitor’s “writable memory” column, which is probably the best measure I can easily take. So here are those numbers:

Player CPU % Writable memory
Songbird 1.1.1-0ubuntu1~fta4 16 94.3 MiB
Rhythmbox 0.12.0-0ubuntu4 3 32.5 MiB
Banshee 1.4.3-4~hyper1+jaunty1 3 44.5 MiB
Exaile 0.2.14-0ubuntu2 2 60.6 MiB
Listen 0.5-6ubuntu1 2 82.2 MiB

18 Responses to “4 GiB? Try 6.”

  1. [— Certainly there’s no basis for statements like “3-10x more memory than RB” —]

    Certainly there is, when one is trolling as hard as one can 😛

  2. Interesting that Banshee is actually one of the smallest in terms of Virtual Memory /and/ Resident. While Rhythmbox is slightly smaller (by 16MB) in terms of Resident, its virtual memory is quite a bit larger (over 100MB larger).

    For everyone’s convenience, I figured it should be explained what each of these columns actually means:

    RES: This is the amount of physical RAM that a process is using at the moment, discluding memory that has been swapped out or that is shared.

    VIRT: This is the total amount of memory the process is using including swap and shared libraries.

    So depending on how you look at it, Banshee is quite a bit more memory efficient than any of the other players (except Exaile which uses slightly less virtual memory, but of course has half the functionality).

    But even if physical RAM is all you care about (and, uh, that value is just a snapshot value, folks), Banshee is still the second smallest memory user.

  3. @alphaomega, VIRT isn’t actual memory – it’s address space. Which isn’t the same thing. Whilst the number is still interesting, it tells a very different story to memory consumption (i.e. these players aren’t all eating a gig of RAM).

    One interesting observation which may explain things a little: Rhythmbox is the only player here which doesn’t use SQLite for its library. Instead, it uses flat XML files. This strikes me as a slightly odd decision, though I suspect it’s impossible to change it now without major rewrites to the app. I can certainly see the act of loading the entire XML file into a data set as RAM-hungry, especially with larger libraries

  4. @directhex, Ah, thanks for fixing my misunderstanding of the values.

  5. @alphaomega,

    I suspect he’s on a 64bit system, where VIRT is inflated by shared libraries to a point that it’s meaningless.

    Dumping a bunch of numbers out is never useful, because people who don’t know any better will just spread false rumors. I suggest that the VIRT column to be removed or at least a strong warning that those numbers are meaningless.

  6. @Ka-Hing Cheung, re-measured. Someone else already told me off for using VIRT.

  7. Cool, 6 Gib ram looks awesome to have. Very nice!
    I’m still with the (too) common 1Gb ram… 🙁

  8. That’s not fair, Jo. You’re not supposed to actually *measure* these things! How do you expect people to write incendiary blog posts with awesome headlines if you go and ruin it with actual data?

    Typical evil Mono proponent behavior…

  9. have you try 6 non imaginary girlfriends .. ?

  10. I suspect my 1 non-imaginary wife might disapprove.

  11. @directhex, so bad 🙁

  12. XMMS2 0.6 DrMattDestruction cpu 1% virt: 544M res: 3160k

  13. Yeah, a daemon. Great choice for a GNOME desktop. *clapping*

  14. >Yeah, a daemon. Great choice for a GNOME desktop. *clapping*

    You brought up Gnome, I did not. Personally, I run Awesome WM (although most of my non-CLI apps are GTK or or Gnome). Anyway, I just threw that out there for fun.

  15. @Kelly Clowers,

    I think his point was mostly that you’re comparing apples and oranges there. For a more apples-apples comparison you’d need to add the memory usage for both xmms2 a controlling GUI.

    Though as with all these memory comparisons, you also should really take into account what features are offered in the GUI. It’s easy to make an app that does essentially nothing and also takes up very little memory. It’s hard to make an app that does a lot and also takes up very little memory. The trade is, as always, features versus memory.

    For example, can xmms2 sync to/from your portable media device? 😉

  16. @Alan,

    Which actually brings me to a more important realisation. All the above apps (to the best of my knowledge) are media centre applications. They handle everything media related. xmms2 is purely a media player, so it’s in a different category.

    So yes, it’s an interesting point in that we have a baseline to compare against when all you want to do is play music. But as a comparison to media centre applications, it’s not quite as useful.

  17. Try using smem for actually acurate memory usage reporting.

    Requires a new (>2.6.27 I think) kernel.

  18. Interesting. Never seen this tool. Which output would you suggest sharing with people?

Leave a Reply