Fighting Daemons

One of the things I love about GNOME and Linux in general is the philosophy of "do one thing, and do it right". However, we may have taken this to an extreme in the GNOME community. The GNOME desktop has seperate daemons for a plethora of simple tasks. nm-applet sits around and waits for the network connection status to change. Great, I love nm-applet. But does this task warrent 2.7 MB of memory? According to my smem script, this is the amount of private dirty rss the task takes.

To initialize the GTK+ framework (among other frameworks), one must allocate a given amount of memory on the heap. Depending on what parts of the stack (dbus, libgnomeui, etc) one loads, this ranges from 1-3 MB. While it's important to work to fix this (eg, by mmaping things), there's only so much we can do.

I believe it would be beneficial to have a host process for daemons like this. The system would need to be set up in such a way so that mini-daemons could be put into a different process via configuration (eg, for debugging).

One of the types daemons on the desktop is panel applets. We have a process to display the clock, the volume switcher, etc. The panel already has a framework for doing these in process. What would be the benefit of using this? To find out, I put two applets in process: the wnck-applet which handles the workspace switcher and task list and the notification-area-applet, which handles the notification tray.

I actually already had the patch for this. openSUSE already uses a similar patch thanks to Federico. I decided to modify the patch so that it would not put clock-applet in process. Some people have complained that because this links to evo, it might be at risk for crashing. Fine, whatever. Let's start with some low hanging fruit.

Here are the results for private dirty rss, before and after the patch.

Process	Before	After
gnome-panel	4008 kb	4248 kb
notification-area-applet	1368 kb	--
wnck-applet	3056 kb	--
TOTAL	8432 kb	4248 kb

This is over 4mb! Just for putting two things in process. There are three other applets on my Dapper computer that could benefit just as easily: trash-applet (trivial), mixer applet (see below), clock applet (links to evo stuff. maybe?). I hope other distros follow the led of openSUSE in this area.

One thing to look at: the mixer applet loads every single part of gstreamer. This causes extra memory usage (gstreamer plugins badly need constification), as well as extra spinning of the disk. Can this be fixed?

Google

I will be interning at Google this summer in the AdWords anti-fraud team. This is a really exciting opportunity for me.

I'd like to publicly thank my friends and colleagues on the Mono project for the fantastic learning experience I've had over the past three years. There are a few people I'd like to give an extra-special thanks:

• Sebastien, for guiding me through my first project, BigInteger.
• Atsushi, for guidance on the project I'm probably most proud of, the XSLT engine.
• Paolo, for code reviews that have begun to teach me the meaning of "good style" (and I admit, I'm still learning).
• Miguel, for believing in me and being a great mentor/friend/boss.

I'll still work with Mono on the side and stay in touch via IRC and email.

If you are a college (or high school student) reading this, I would like to give you one piece of advice. Get involved in an open source project. It will be the best choice of your life. Even the world's best computer science schools are very bad at teaching you what you really need to know to get work done. CS classes teach theory, not how to write good code. Hacking on open source software is the best way to be a smart programmer. Open source projects are more than happy to take on a dedicated hacker, even one who makes mistakes at first. Hacking will be the best decision you ever made. Your chances of getting an internship are greatly increased by working on OSS.

As a side note: for those of you who missed my previous blog because pgo wasn't picking up my feed, I'm going to GUADEC. Be prepared to kill bloat.

(I promise performance blogs are coming soon. Really)

Newslets

• I'm going to GUADEC, now that I am being sponsored. Be prepared to kill bloat with the Ben, Federico, Behdad team. If you're interested in memory reduction, it'd be great to have you.
• With leadership from Daniel Holbach, Ubuntu will be using the icon cache. Yay.
• I promise for some more juicy memory reduction content soon, after I finish 15-251 (Discrete Math) homework.

More Icon Cache

It's too bad that we are at a standstill as to using the GTK Icon Cache in Ubuntu/Debian. Clearly, both Fedora and SUSE have implemented the standards defined policy and have (to my knowledge) not encountered major issues.

While the impressive number of over 300 packages quoted on the Ubuntu bug seems like a very hard task, distributed across many contributers, I can't imagine this being a blocking issue. As for 3rd party apps: sure, could cause a third party app to break. But the same app will be broken on any other issue.

Even if the Debian folks absolutely do not want to risk breaking something, how about at least using the shared memory aspect of the cache? You can stat every directory in /usr/share/icons to make sure the cache is valid. But if it is, you'll save 300kb per process by using the cache.

Anyways, it looks like the spec is staying as is. The folks upstream have given (IMHO) a well reasoned argument that the spec is implementable and reasonable.