The new markup-tree stuff

[Philip Van Hoof <spam pvanhoof be>]

I've been studying the markup-tree.c stuff recently.

I noticed one issue with it. I understand that now it's cached. So once
a path is read, it's in memory. That will for sure be a speed
improvement.

However. The biggest problem with GConf is that it's slowing down the
__startup__ of a GNOME desktop. It's doing that because at this moment,
only one thread reads files. This serializes everything.

I'm not seeing how the markup-tree.c is going to change that. Simply
because the cache, at startup, is cold. So the files still need to be
read one by one, that first time. Once all those files are loaded, it
will be faster indeed. But not for the startup (cold cache).

We could fix this by preloading some typical paths. Or by making
markup-tree.c thread-safe and launch a pool of worker threads that will
do the reading of paths (and g_idle the GMainLoop about when such a file
is read, so that it can inform the client etcetera). But thats just an
idea of course.

It sounds exciting and fun to do experiments with all this. Nothing
wrong with doing experiments, right? :-)


Any thoughts from the current GConf developers?


-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.pvanhoof.be/