Re: easy login time win

[David Malcolm <dmalcolm redhat com>]

On Sun, 2004-11-21 at 03:59 -0500, Havoc Pennington wrote:
> Hi,
> 
> Some of the "boot poster" results from FC3 showed gconf eating a lot of
> time during login.
> 
> If you do:
> 
> time gconftool-2 --config-source=xml:readonly:/etc/gconf/gconf.xml.defaults --direct -R / > /dev/null
> 
> that reports only 3-4 seconds on the second run (disk access out of the
> picture), but it's still 3-4 seconds. Disk access at least doubles it.
> 
> I've been profiling gconf tonight and I believe that most of this is
> coming from loading the XML for all the translations of the short and
> long descriptions. Only gconf-editor needs these, but they are making
> the XML files large. And gmarkup.c does a fairly alarming amount of work
> per-character.

Looking at the Makefile.am, when did we start using GMarkup rather than
libxml2?   Anyone know what the relative speeds of GMarkup vs libxml2
are?

> 
> I started micro-optimizing gmarkup.c, but that isn't the best approach
> here. To get the big win we should be able to just remove this whole
> block of work from the login process.
> 
> One thought is to do an mmap cache as we have for icon themes, and in
> the mmap format be sure to split the short/long descriptions into their
> own half of the file. We could then try to avoid ever touching that
> half. Some additional hacking inside gconf to keep it from ever asking
> for the full schema object may be required to get that far.[1]
> 
> There could be other approaches. Of course Future GConf
> as described at http://www.gnome.org/projects/gconf/plans.html does not
> have this problem, but I think it's worth fixing in Today GConf.
> 
> Maybe a good project for someone... should bring noticeable speedups.
> 
> One caveat, I haven't profiled gconf during login; I'm assuming that 
> gconftool-2 --config-source=xml:readonly:/etc/gconf/gconf.xml.defaults --direct -R / > /dev/null
> is a reasonable approximation of what it does at login time. Conceivably
> I'm wrong about that.
> 
> Havoc
> 
> [1] to implement this I'd add a get_default_from_schema() to the backend
> vtable and use that instead of the query_value() to get at the schemas,
> or something along those lines.
> 
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list