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/ _______________________________________________ gconf-list mailing list gconf-list@gnome.org http://mail.gnome.org/mailman/listinfo/gconf-list