-
cacharro$ ps aux | grep evo federico 11506 0.0 29.7 307960 153604 ? S Jan10 39:14 evolution federico 11508 0.0 1.0 852620 5496 ? S Jan10 0:02 /opt/gnome/lib/evolution-data-server-1.0 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_InterfaceCheck --oaf-ior-fd=51 federico 11519 0.0 0.9 64972 4984 ? S Jan10 0:23 /opt/gnome/lib/evolution/2.0/evolution-alarm-notify --oaf-activate-iid=OAFIID:GNOME_Evolution_Calendar_AlarmNotify_Factory:2.0 --oaf-ior-fd=56
It's a stable pig.
-
I compared the memory usage of two runs of gedit, one with LANG=en_US.UTF-8 and the other one with LANG=es_MX.UTF-8. This is just launching gedit and running pmap(1); no documents got loaded. The results are interesting:
Oddly enough, the English version has a larger total VM size. However, the Spanish version has more writable data.
It would be interesting to run this with RML's hack to get RSS info from pmap.
-
Also, what about LANG=C, to get a bare-bones measurement? The collation tables in English seem to be huge. And what's with all the bookkeeping for the non-English case?
-
Thoughts about using Gnumeric for this:
-
Gnumeric's fixed-width text import absolutely rocks. I'd prefer a clearer indication of where exactly you are invoking its "split here" thingy in the column picker.
-
Gnumeric lacks conditional formatting. So, adding a bold attribute to cells whose values are different was a manual process.
-
The syntax for =SUMIF() is totally non-intuitive. Fucking Excel.
-
The exported HTML is too big. Style attributes for cells are duplicated on each <td>. Maybe the HTML export module could make use of Gnumeric's fantastic quadtree of cell styles.
-
-
Alex posted a cute patch to GObject that lets you add instrumentation code to track memory usage. Basically, you register a callback that can add up all the memory used by an object's internal data. Maybe this could be done somewhat more automatically if (say) memprof would let you group together related functions which allocate memory on behalf of an object; then it would display the accumulated results. Currently it only groups per stack trace, which is very useful, but you still need to hunt for other allocations.
A managed runtime may be able to do this automatically resasonably easily. The only trick is to handle recursive or circular data structures.
-
Dave: thanks for the recipe!
-
Robert wrote a patch to let the kernel and pmap(1) report RSS information. This lets you roughly watch the working set of a program. Ben then ran some tests on a GTK+ program that just displays a "Hello world" button inside a window. The numbers for the code VMAs are interesting [log trimmed]:
VMA size RSS 41399000 504K 312K r-xp /opt/gnome/lib/libglib-2.0.so.0.400.6 4150d000 224K 224K r-xp /opt/gnome/lib/libgobject-2.0.so.0.400.6 4162b000 3064K 768K r-xp /opt/gnome/lib/libgtk-x11-2.0.so.0.400.14 b794a000 44K 36K r-xp /opt/gnome/lib/gtk-2.0/engines/libindustrial.so-
312 KB of RSS of GLib code sounds like a lot for a "utility" library, doesn't it?
-
224 KB for GObject. Why is all of GObject's code loaded? Is it just small enough to keep it in core? Or perhaps initializing the fundamental types and the basic GTK+ types really does exercise most of the code.
-
768 KB for GTK+. Sounds like an awful lot is getting touched to paint just a window and a button.
-
36 KB for the Industrial theme engine. Ditto — for just a window a button, it should only touch the code for the paint_flat_box() and paint_shadow() implementations.
Maybe this is an indication that we need function reordering, a la Nat's Grope. [What is the current status of compiler/linker tools for function reordering?] If the functions are scattered around right now, then that could explain why we are touching so many code pages for a trivial app.
Also, I'd love to see the results of using gcc -Os to optimize for size rather than the typical -O2.
Currently it looks like there is no way to see which actual pages are in core. We could use that to see which functions are loaded: if related functions are very scattered around, and so unused code is polluting the extra space in the required pages, then we do need function reordering.
-
-
Update: It looks like someone is developing a tool to do function reordering already!
-
Chipx86: Here's a really quick patch for Gaim to make it use the HTTP proxy settings that live in GConf. It's what we'll be using in the next version of NLD.
-
The memory reduction wiki page now has a progress tracker, and the first bug is squished!
-
If you search for "aeiou" in Google, it also matches web pages which have "áèïôu". This is useful because it lets you find pages with bad spelling, but that nonetheless contain the information you want. Here's a quick-n-dirty way to strip diacritics.
-
Ulrich Drepper has a weblog!
-
Who wants to go profiler-happy on the GTK+ stack to reduce memory consumption? Some starting points:
- Ben Maurer talks about how GTK+ 2.6 apps use less memory than 2.4 apps.
- Miguel on how the GTK+ 2.0 series is bigger in general than the 1.2 series.
- Scott Arrington does a poll on startup time and concludes that startup is fast enough. Still, Tommi Komulainen asks about startup time on small devices.
-
Today's GTK+ team meeting is scheduled improptu and will deal with memory consumption. Ben Maurer has promised to give us something to chew on.
Update: the meeting log is up; I'm distilling it into the MemoryReduction page that Ben started in the wiki.
-
Oralia doesn't give classes on Mondays, and today she cooked up a storm. For breakfast, we had the peach/strawberry/plum preserve which she made yesterday, spread over bread with butter.
For lunch she made a really good octopus tempura. It's amazing how expensive this is in Japanese restaurants; about 4x the price we paid for the ingredients.
But the best thing was what we had for dinner, a fantastic cream of cauliflower, with strips of red and yellow pepper. To spice it up, dillweed, peppercorns, a bit of Dijon mustard, and habanero juice. It looked colorful, and it smelled and tasted delicious. It reminded me of an Austrian restaurant that my parents used to take me to when I was a 5-year old kid. They always had delicious soups like that, but you could never figure out what they were made of. The restaurant (I'm not making this up) was called El Gnomo Perezoso, "The Lazy Gnome". The bathroom walls were papered with sheets from Rien Poortvliet's book on gnomes.
-
Daniel writes about the pressure to have software patents in Europe. "Pressure" and "verbal violence" reminded me of last year, when I was at the amazing HP research building. The first thing that greets you after you step out of the elevator is a wall covered with gold-plated patent grants. Man, I should have taken a picture. They were hung like trophies on a huntsman's wall. I looked at them during conference breaks; some were for exotic things, other for ridiculously obvious ones. The one I remember the most was about how to promote pixel values for low bit depths into values with higher bit depths. You know, like when going from RGB at 8 bits per channel to 16 bits per channel, so you have to map the range [0, 0xff] into a wider range [0, 0xffff]. You can't just shift by 8 bits to the left; you have to copy the value into the lower bits. So, 0xab becomes 0xabab; the typical symptom of not doing this is where 100% white becomes almost-white. The abstract of the patent and a cute diagram, gold leaf, fancy frame and everything, described exactly that; the only particular thing is that it seemed to describe a hardware implementation.
-
Guadec will take place in a palace this year. Powdered wigs and fluffy sleeves will be mandatory for all attendees.
-
Novell released the source for the Hula Project, a calendar and mail server! Nat has more details in his blog.
-
How do you figure out the index of the selected item in a GtkRadioButton group? The control center uses this:
enum ProxyMode { PROXYMODE_NONE, PROXYMODE_MANUAL, PROXYMODE_AUTO }; static void proxy_mode_radiobutton_clicked_cb (GtkWidget *widget, GladeXML *dialog) { GSList *mode_group; int mode; if (!gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON(widget))) return; mode_group = g_slist_copy (gtk_radio_button_get_group (GTK_RADIO_BUTTON (WID ("none_radiobutton")))); mode_group = g_slist_reverse (mode_group); mode = g_slist_index (mode_group, widget); g_slist_free (mode_group); if (mode == PROXYMODE_MANUAL) ...I filed bug #166995 about this. Hopefully kittens will stop getting killed once this is fixed in GTK+.
-
I just discovered that XDevConf is happening again this year in Cambridge. But it is next weekend, damnit. It's too late to plan a trip now. Sigh.
-
The panel in 2.10 has a new menu layout. It also reads your ~/.gtk-bookmarks file. This is great from the user's viewpoint; you can visit your bookmarked folders from the panel. But from the GTK+ viewpoint, it's not so good: it will keep us from changing the .gtk-bookmarks format during the 2.6.x series.
We should be able to get bookmarks and recent-files right for GNOME 2.12 and GTK+ 2.8. We need a public API for those at the GTK+ level, with hopefully an updated recent-files specification to standardize it underneath.
-
Dave: If you are interested in panos, check out this panorama workflow. The author is a great photographer, screenwriter, and pano junkie. He also taught me how to develop B&W film over IRC :)
-
Sometimes, when writing something with OpenOffice, you need both portrait and landscape pages in the same document. It's not obvious at all how to do that.
-
If you have a low-end machine with a 16 bits-per-pixel graphics card, all your GTK+ processes likely use exactly 64 extra KB than would ideally be needed. GdkRGB has a lookup table for its dithering functions that gets mangled at runtime for machines with 565-bpp RGB displays. The original lookup table is properly const, so it lives in the shared read-only section of the library. However, the mangled table is allocated dynamically. Go fix it; your low-end machine will appreciate the memory increase.