internal fragmentation

a personal journal of hacking, science, and technology

Gnote vs Tomboy memory showdown with smem

Wed, 11 Nov 2009 14:47 by mpm in Uncategorized (link)

As an illustration of my recent release of smem 0.9, here’s how Gnome desktop rivals Gnote and Tomboy compare on memory usage.

Methodology: take a normal GNOME desktop and add either Gnote or Tomboy to a panel. Restart X, open a single terminal window, take a process size measurement, open up the “Search All Notes” window, take another process size measurement, then measure libary sizes.

Here’s what the output for a freshly-started Gnote looks like:

# smem -P gnot*e -t
  PID User     Command                         Swap      USS      PSS      RSS
 8552 mpm      /usr/bin/gnote --panel-appl        0    13652    14915    23896
-------------------------------------------------------------------------------
   87 1                                           0    13652    14915    23896

‘RSS’ (resident set size) is the measure reported by most tools, and shows 23.8MiB of memory usage by Gnote. But that number is misleading as it counts all the memory used by numerous shared libraries (Gnote uses about 170 shared mappings). In fact, most developers (rightly) ignore this number as meaningless and (not so rightly) assume that the bulk of memory usage is shared.

If we compare running Gnote and not running Gnote, we’ll see a much smaller difference in memory usage. In fact, the difference we’ll see is in the table above as ‘USS’ (unique set size). There’s 13.6MiB of memory that’s used only by Gnote. The remaining 10.2MiB is shared with other applications. ‘PSS’ (proportional set size) accounts for that difference by dividing up shared ownership of libraries on a page by page basis. If you add up the PSS of all the processes on the system, they will sum to the total (userspace) memory usage.

So, Gnote’s real share of memory is 14.9MiB, once sharing is accounted for. Fairly expensive for having only drawn a 32×32 icon so far. Hell, that’s fairly expensive for a full-featured GUI environment and wordprocessor by mid-’90s standards, but I digress.

Now let’s look at a freshly-started Tomboy:

# smem -P tom*boy -t
  PID User     Command                         Swap      USS      PSS      RSS
 7873 mpm      bash /usr/bin/tomboy-panel         0      464      652     1612
 7885 mpm      mono /usr/lib/tomboy/Tomboy        0    21732    22618    31116
-------------------------------------------------------------------------------
   89 1                                           0    22196    23270    32728

First note that Tomboy here is getting launched by an extra persistent copy of bash that chews up an extra 652KiB of memory. But the numbers for the main process are all larger also (by about 8MiB, 7.7MiB, and 7.2MiB respectively). 6.9MiB of that is 21 Mono libraries that are only used by Tomboy (at least on my desktop):

$ smem -m -M mono -t
Map                                       PIDs   AVGPSS      PSS
/dev/shm/mono.9295                           1        4        4
/usr/lib/mono/gac/NDesk.DBus.GLib/1.0.0.     1        8        8
/usr/lib/mono/gac/gconf-sharp/2.24.0.0__     1       12       12
/usr/lib/mono/gac/gnome-panel-sharp/2.24     1       16       16
/usr/lib/mono/gtk-sharp-2.0/libglibsharp     1       16       16
/usr/lib/mono/gtk-sharp-2.0/libgdksharpg     1       24       24
/usr/lib/mono/gac/gmime-sharp/2.2.0.0__2     1       48       48
/usr/lib/mono/gac/atk-sharp/2.12.0.0__35     1       56       56
/usr/lib/mono/gac/pango-sharp/2.12.0.0__     1       60       60
/usr/lib/mono/gac/NDesk.DBus/1.0.0.0__f6     1       72       72
/usr/lib/mono/gac/glib-sharp/2.12.0.0__3     1       84       84
/usr/lib/mono/gtk-sharp-2.0/libgtksharpg     1       92       92
/usr/lib/mono/gac/gnome-sharp/2.24.0.0__     1      140      140
/usr/lib/mono/gac/Mono.Posix/2.0.0.0__07     1      172      172
/usr/lib/mono/gac/Mono.Addins/0.4.0.0__0     1      180      180
/usr/lib/mono/gac/gdk-sharp/2.12.0.0__35     1      180      180
/usr/lib/mono/gac/System/2.0.0.0__b77a5c     1      644      644
/usr/lib/mono/gac/System.Xml/2.0.0.0__b7     1      652      652
/usr/lib/mono/gac/gtk-sharp/2.12.0.0__35     1     1116     1116
/usr/bin/mono                                1     1648     1648
/usr/lib/mono/2.0/mscorlib.dll               1     1660     1660
-----------------------------------------------------------------
21                                          21     6884     6884

Here’s the PSS numbers including firing up search:

Tool Startup Search
Gnote 14915 16929
Tomboy 23270 27197

Conclusion? They’re both hopeless bloated, but Tomboy considerably more so. Next up: gweather, which takes 5MiB to tell me I should be outside enjoying the sunshine.

Dogs and SUVs

Fri, 6 Nov 2009 21:08 by mpm in Uncategorized (link)

There’s a new book out by a pair of architects that’s triggering a lot of clueless pop science news articles with their claim that the ecological impact of a dog is higher than an SUV.

But none of their methodology actually stands up to any scrutiny (never mind their numbers). Their argument is that feeding a dog (as measured in calories) requires more hectares of land to sustain than an SUV (as measured in joules). By looking at the amount of land theoretically required to produce x calories of food and comparing that to the amount of land to theoretically produce y joules of energy, they arrive at a ratio. Simple enough?

The basic problem is that oversimplified theory and practice don’t agree. First, most dogs’ diets consist almost entirely of food that would otherwise be waste product, as it’s not fit for human consumption. So taking a measure for land productivity for human food production and using that as a proxy for a dog’s eco-footprint is basically meaningless. Their actual food impact is so small it’s hard to measure. Also note that dogs are “built” from renewable materials with very low upfront energy costs.

In contrast, SUVs aren’t built from renewable materials and don’t run on renewable fuels so their footprint can’t be measured. There are no solar-powered SUVs and the energy efficiency of biodiesel is extremely low (and thought to be negative in many cases). And if we started running all the SUVs in the world on today’s biodiesel, there would be no land left to grow food (there are already food riots being caused by ethanol demand). So the effective eco-footprint of an SUV is tremendously higher than the theoretical fraction of a hectares per year they quote.

Compare these two meaningless numbers and you get a result that is orders of magnitude out of touch with reality. If your instinct tells you that a 15kg dog chasing a ball around the yard and basking in the sun uses less of the world’s resources than an 2500kg SUV roaring down a freeway or sitting in traffic, you’re right.

1.4 release plans

Wed, 4 Nov 2009 14:20 by mpm in Uncategorized (link)

Spoke with our legal counsel from SFLC this morning and determined that we should probably not hold up the release process any further. So the 1.4 feature freeze will be this Saturday, followed by a release on November 16th. This release will still be under the old GPLv2 only license, but will have SVN conversion support enabled.

The relicensing process is mostly about having all our ducks in a row to make distributors and co-developers happy. We’re 98% done, but the end game is hard due to people that can’t be located. I expect we’ll have this wrapped up in time for the 1.5 release on March 1st.

The best way to help make the 1.4 release a success is of course to run the latest development version from the main repository and report any problems you encounter. There are also nightly builds available for Windows users. We generally keep our development tip end-user ready at all times (and do all our own day to day work with it), so testing tip is pretty safe.

Mercurial 1.4 delayed

Tue, 3 Nov 2009 16:25 by mpm in Uncategorized (link)

I spent most of October arguing with people about licenses, talking with lawyers, and tracking down contributors for our big relicensing effort but we haven’t quite finished yet so I’m letting our scheduled Nov 1st date slide. If it’s not sorted out in a couple weeks, we’ll cut a release anyway.

A lot of the work that I hoped would happen for 1.4 didn’t get done, but we’ve been getting a steady stream of nice usability improvements. The one I’m most excited about is the new summary command, which combines the output of a bunch of commands in one place, giving you a quick view of what’s going on in your repo:

$ hg sum --remote
parent: 9665:1de5ebfa5585 tip
 walkchangerevs: drop ui arg
branch: default
commit: 15 unknown (clean)
update: (current)
remote: 1 or more incoming

Twittering

14:45 by mpm in Uncategorized (link)

You can follow me at mpmselenic.