Sunday, January 25, 2009


Dear Gnome,

This is completely ridiculous. According to top, "clock-applet" is using 353M virtual memory, of which 17M is resident. I have no swap partition, so it really makes me wonder why those 336M were allocated in the first place. If they are not resident, and not in swap, what are they? Blank pages? mmap()ed files which can be swapped in on demand?

There is also a column for "shared memory", which says 12M. Does that mean that 12M out of those 353M are shared with one or more other processes? What is this shared memory, library code and mmapped files?

Isn't 17M also too much for "clock-applet"? It should be one of the simplest applications that run on my desktop. It would be interesting to know what all of this memory is used for. I think that most of it is library code. And here's an indication...

$ ldd /usr/libexec/clock-applet => (0x00007fffb1fff000) => /usr/lib64/ (0x000000000062c000) => /usr/lib64/ (0x000000000083b000) => /usr/lib64/ (0x0000000000b46000) => /usr/lib64/ (0x0000000000d48000) => /usr/lib64/ (0x0000000000fe2000) => /usr/lib64/ (0x0000000004d22000) => /usr/lib64/ (0x0000000006c5b000) => /usr/lib64/ (0x00000000011ea000) => /usr/lib64/ (0x00000000064a7000) => /usr/lib64/ (0x00000000060ef000) => /usr/lib64/ (0x00000000077c7000) => /usr/lib64/ (0x0000000001c1c000) => /usr/lib64/ (0x0000000001453000) => /usr/lib64/ (0x00007f61a9ca3000) => /lib64/ (0x00007f61a9a99000) => /usr/lib64/ (0x00007f61a986f000) => /usr/lib64/ (0x00007f61a962b000) => /usr/lib64/ (0x00007f61a93b6000) => /usr/lib64/ (0x00007f61a919b000) => /usr/lib64/ (0x00007f61a8f2c000) => /lib64/ (0x00007f61a8d27000) => /lib64/ (0x00007f61a8b1e000) => /usr/lib64/ (0x00007f61a8905000) => /usr/lib64/ (0x00007f61a85a8000) => /usr/lib64/ (0x00007f61a8373000) => /usr/lib64/ (0x00007f61a8153000) => /usr/lib64/ (0x00007f61a7f15000) => /usr/lib64/ (0x00007f61a7d0a000) => /usr/lib64/ (0x00007f61a7afe000) => /usr/lib64/ (0x00007f61a78f3000) => /usr/lib64/ (0x00007f61a731e000) => /usr/lib64/ (0x00007f61a7105000) => /usr/lib64/ (0x00007f61a6e66000) => /usr/lib64/ (0x00007f61a6c46000) => /lib64/ (0x00007f61a69d2000) => /usr/lib64/ (0x00007f61a67a4000) => /usr/lib64/ (0x00007f61a6587000) => /usr/lib64/ (0x00007f61a637c000) => /usr/lib64/ (0x00007f61a6107000) => /usr/lib64/ (0x00007f61a5ebe000) => /usr/lib64/ (0x00007f61a5c25000) => /usr/lib64/ (0x00007f61a59f3000) => /lib64/ (0x00007f61a57b0000) => /lib64/ (0x00007f61a55ad000) => /lib64/ (0x00007f61a52cb000) => /lib64/ (0x00007f61a508d000) => /usr/lib64/ (0x00007f61a4e75000) => /lib64/ (0x00007f61a4c58000) => /lib64/ (0x00007f61a48e6000) => /lib64/ (0x00007f61a4661000) => /usr/lib64/ (0x00007f61a445f000) => /usr/lib64/ (0x00007f61a4244000) => /lib64/ (0x00007f61a403f000) => /usr/lib64/ (0x00007f61a3e2d000) => /lib64/ (0x00007f61a3c28000) => /lib64/ (0x00007f61a39d9000) => /lib64/ (0x00007f61a3675000) => /lib64/ (0x00007f61a3460000) => /usr/lib64/ (0x00007f61a325d000) => /usr/lib64/ (0x00007f61a3050000) => /usr/lib64/ (0x00007f61a2e40000) => /lib64/ (0x00007f61a2c28000) => /lib64/ (0x00007f61a2a0b000) => /lib64/ (0x00007f61a2808000) => /usr/lib64/ (0x00007f61a2601000) => /usr/lib64/ (0x00007f61a23e6000) => /usr/lib64/ (0x00007f61a216b000) => /lib64/ (0x00007f61a1f67000) => /lib64/ (0x00007f61a1d63000) => /lib64/ (0x00007f61a1b26000) => /usr/lib64/ (0x00007f61a187b000) => /lib64/ (0x00007f61a1608000) => /usr/lib64/ (0x00007f61a1401000)
/lib64/ (0x0000000000110000) => /usr/lib64/ (0x00007f61a11c3000) => /usr/lib64/ (0x00007f61a0f87000) => /usr/lib64/ (0x00007f61a0d61000) => /lib64/ (0x00007f61a0b47000) => /usr/lib64/ (0x00007f61a0944000) => /usr/lib64/ (0x00007f61a0742000) => /usr/lib64/ (0x00007f61a053c000) => /lib64/ (0x00007f61a0313000) => /usr/lib64/ (0x00007f61a0102000) => /usr/lib64/ (0x00007f619fef8000) => /usr/lib64/ (0x00007f619fcf6000) => /usr/lib64/ (0x00007f619faed000) => /usr/lib64/ (0x00007f619f8e5000) => /usr/lib64/ (0x00007f619f6db000) => /usr/lib64/ (0x00007f619f496000) => /lib64/ (0x00007f619f292000) => /usr/lib64/ (0x00007f619f08c000) => /usr/lib64/ (0x00007f619ee5d000) => /usr/lib64/ (0x00007f619ebbb000) => /lib64/ (0x00007f619e9b7000) => /usr/lib64/ (0x00007f619e792000) => /lib64/ (0x00007f619e559000) => /lib64/ (0x00007f619e327000) => /lib64/ (0x00007f619e0fc000) => /lib64/ (0x00007f619dda1000) => /lib64/ (0x00007f619db84000) => /usr/lib64/ (0x00007f619d91b000) => /usr/lib64/ (0x00007f619d70a000) => /lib64/ (0x00007f619d507000) => /lib64/ (0x00007f619d2f6000) => /usr/lib64/ (0x00007f619d0ec000) => /lib64/ (0x00007f619cee9000)

I think that's insane. Is all of this really needed? As a random example, what is Oh, of course...

$ rpm -q -f /lib64/

$ yum search e2fsprogs-libs
e2fsprogs-libs.i386 : Ext2/3 filesystem-specific shared libraries and headers

So I wonder... is this why the memory usage of clock-applet blows up, does it really matter, and can we do anything about it?

I have a feeling that this is yet another sign of how the GNU/Linux desktop is heading the wrong way. It smells a lot like bloat :-(



Alturin said...

Bloat? Smells like Windows. Maybe they should add something with fancy tiling windows that show you which apps you are running? Or we should integrate a browser...

(Sad thing is Konquerer is about as bad as Internet Explorer about the whole doing-everything-and-the-kitchen-sink thing.)

Ananias said...

in true Geek-Tao mode, and volume of voice:


that's just obscene!