Re: PROPOSAL: GNOME Volume Manager for GNOME 2.8

[Havoc Pennington <hp redhat com>]

On Fri, 2004-06-25 at 20:01, Alan Cox wrote:
> Definitely. I'd like to stress the stuff I've done isn't going to help
> gconf just icons/themes however. The database problem with dynamic
> fast updates is a *much* harder problem - paradoxically it might 
> actually be quicker to dump the entire gconf db into a file each 
> changeset than to write a set of changed nodes.

With the merge trees patch Mark is putting in 2.8 and the markup backend
we put in 2.6, gconf may not be that bad anymore really. In principle it
should now be about the same as any other dotfile
(there's basically just one dotfile per app with the merge trees, and
the markup backend is not that inefficient).

Of course all the dotfile-loading is going to be in the gconfd process,
not in the main app process, and we do shove the stuff over a socket.
With "one big dotfile" we do make writes a lot slower but probably
nobody cares.

You could certainly do better with gconf by using a database type of
thing rather than text files, but I bet it would be more worthwhile to
hack on reducing per-app overhead (if we can fix the icon theme stuff,
maybe do something with fontconfig/pango, or whatever else is in the
profile, and we're on track to get rid of much of the GNOME library
stack also I think by moving the last bits of gnomeui etc. into gtk for
GNOME 2.10 and killing all the cruft)

We're still suffering in my opinion from lack of a memory profile of the
whole desktop session, showing % memory from icon theme cache aggregate
for all apps, % memory from fonts for all apps, etc. etc.
i.e. there's no overall profile of the desktop - we have no idea for a
desktop with email, browser, office suite using 192M what is using up
the 192M by percentage.

Saving .5M per app with the mmap icon theme cache is clearly a win
regardless, but in terms of "can we actually get from 192M to 128M for a
full desktop?" it's hard to know what's involved and whether it's easy
or hard at this point. On some level going from 192M to 170M isn't very
useful, we have to get down to 128M.

Some people have suggested that per-email memory usage of Evo - since
Evo's mem usage seems to depend largely on number of mails - and
chilling out caching across the desktop (including the obvious such as
the browser, but we have little caches all over every app for all kinds
of things) might be some important ways to get us smaller.

One item is that GConfClient caches settings client-side by default, I
think there's a call to dump the cache after initial load, but
GConfClient could just be smart about getting rid of the cache based on
time or most-recently-used. Of course, I have no idea how large this
cache typically is.

Havoc