RTP the second coming and Bloat

Ok, it turned out my list of RTP projects using GStreamer was too short, there are at least two more projects in the GStreamer RTP real under development. The Xeris project have a GStreamer RTP setup using the ortp libary. And there is the Sofia project a console SIP client. Lots of good discussion on the mailing list going on where people try to coordinate the different efforts to get as much synergy effect as possible. Neat stuff.

Bloat and other madness

Jono’s article on O’Reilly caused quite a debate on lwn.net. The GNOME clock applet taking 10M of ram as proof that GNOME was bloated was brought up again. Ross Burton and Stef70 replied explaining why that number is misleading at why the actuall memory use of the applet is more something between 1M and 1.6M. Anyway I ended up chatting a little with Benoit Dejean the maintainer of GNOME System Monitor about it, thinking that even if maybe top and ps is out of our control we could at least make sure GNOME System monitor gives people better numbers. I mean if the numbers you present makes a lot of people draw the wrong conclusion then maybe the conclusion to draw from that is that you are presenting them the wrong numbers.

The problem seems to be that you can’t actually get the ‘real’ number due to the way the system works. And being the engineers we are providing users with an approximation number, (for instance by substracting SHARED memory from RESIDENT memory) violates everything most of us hold holy. So what we are left with are correct numbers which a large number of our users fails to understand/interpret correctly. On the other hand we are hesitant to provide an inaccurate number, but which still would give our users a number much closer to the number they want/expects. I hope someone manage to sort this out someday..

5 thoughts on “RTP the second coming and Bloat”

  1. Wasn’t somebody working a patch to give REAL memory for processes? I must have read that in Linux Journal or another printed mag because beagle can’t find it ;),

  2. Christian-

    You mention that currently we use the “correct numbers which a large number of our users fails to understand/interpret correctly”.

    So, maybe the first place to begin is by educating people in what these numbers mean. My (Gnome v2.10) System Monitor app lists the following memory display options:

    VM Size
    Resident Memory
    Shared Memory
    RSS Memory
    X Server Memory

    I personally have no idea what any of these exactly means.

    Looking at a real example, the System Monitor itself claims that it uses:

    VM Size: 23MB
    Resident Memory: 11MB
    Shared Memory: 8MB
    RSS Memory: 11MB
    X Server Memory: 429MB

    ??

    If someone could go through that listing line-by-line it would be hugely instructive to the ignorant masses (myself included). A quick read-through of the System Monitor help files shows that none of this information is there, perhaps that would be a good place to inform users that are incorrectly interpreting the numbers.

    Thanks!
    -Jon

  3. It would also seem that we could discover which libraries an application uses, and what the size of those are by asking the linker. Something like “ldd myapp” then find the sizes of those libraries, and subtract that from the resident size. I guess there could be other dynamically loaded libraries that ldd wouldn’t give us (i.e. GDK pixbuf loaders), but it would be much closer.

  4. Please don’t take this as an offence, but one million and six hundred thousand bytes for a bit of text in the panel is not bloat?

    I would expect a clock to take no more than a few hundred KB’s.

Comments are closed.