Progress
This page will document our progress in the MemoryReduction effort. The idea is to maintain a list of knowledge about the things we have fixed, how we fixed them, and when.
Share the GdkRGB lookup table for dithering on 16-bit video cards
Problem: GdkRGB, the part of GDK which translates 24-bit image data into the format required by the X server, has a large lookup table used for dithering on video cards with less than 24 BPP. This lookup table is properly const and static, so it gets put in the read-only, shared section of the library. However, when GDK runs on a 16-bit card with 5-6-5 bits for RGB, it copies the lookup table into a malloc()ed buffer and tweaks the values for that bit-depth.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=164940
Solution: The modified lookup table always has the same values, so we can put it in a static const array that is shared and read-only. At runtime, GdkRGB decides which of the two lookup tables to use (the 24-bit one or the 16-bit one).
Date fixed: 2005/Feb/22
Fixed version: gtk+-2.6.3
Fixed by: BenMaurer, TommiKomulainen, FedericoMenaQuintero
Share freetype glyph name tables
Problem: Freetype contains the names for 4293 glyphs which equals to some 16k of data. Because of the way the glyph names are stored, they end up in the .data section consuming that 16k per process.
Bug: http://savannah.nongnu.org/bugs/index.php?func=detailitem&item_id=12262
Solution: Place all glyph names in a big NUL-separated string and use offsets into that string rather than pointers. (Inspired by Owen's solution to bug gnomebug:168899)
Patch: http://www.iki.fi/tkomulai/const-ps_glyph_names.diff (263,1 KB, most of it because of pre-generated table)
Date fixed: 2005/Mar/05
Fixed version: 2.1.10 (2005/Jun/12)
Fixed by: TommiKomulainen
Both gnome-settings-daemon and Nautilus keep background images
Problem: Nautilus and gnome-settings-daemon both use libbackground. However, both keep in-server copies of the background pixmap. Both may also keep client-side pixbufs of the same. So, setting a background image can consume about 13 MB of RAM in total.
The right way to do it is to keep a single in-server pixmap with the background image, and no client-side pixbufs.
Bug: gnomebug:84147 and gnomebug:169347
Solution: Made the buffers shrink if we detect incoming evil thingies. Please use a detailed description of how the problem was fixed.
Date fixed: 2005-03-15
Fixed version: ?
Fixed by: Nickolay V. Shmyrev
vte allocates too much memory for each terminal
Problem: The data structures used by VTE waste a lot of memory which is not used.
Bug: gnomebug:160993
Solution: share _vte_matcher and _vte_termcap structures between multiple terminals
Date fixed: 2005-03-14
Fixed version: vte-0.11.13
Fixed by: Aivars Kalvans
Please use the following format when adding entries to this page:
Trimming of fooapp's buffers
Problem: fooapp maintains and grows buffer for its thingies. However, the buffer can grow to unbounded sizes if the thingies are evil. Please use a detailed description here, as the idea is that this page will serve in teaching people how to locate and fix memory consumption problems.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=42 Link to the Bugzilla bug in question. 
LuisMenina: Why not use the InterWiki format ? gnomebug:42
Solution: Made the buffers shrink if we detect incoming evil thingies. Please use a detailed description of how the problem was fixed.
Date fixed: 2005/Feb/22 This is useful when looking at ChangeLogs or CVS logs.
Fixed version: fooapp-2.9.2, fooapp-2.8.7 Please include the first version in which the fix will appear, so that users will know what to download.
Fixed by: RandomHackerName
GTK+ Stock Items are created as GdkPixbuf for each application
According to Gtk+ developers, this is not an issue. I leave it here for reference (Bug: gnomebug:317933).
While this is not the issue people thought it is, it should be pointed out that GTK+ 2.10 will reduce the memory usage and startup overhead for builtin stock icons by storing them in an icon cache, instead of instantiating pixbufs for each one and storing them in a hash table.