Re: gconf backend

On Sat, Sep 27, 2003 at 10:46:34AM -0400, Havoc Pennington wrote:
> On Sat, 2003-09-27 at 06:44, Daniel Veillard wrote:
> > On Sat, Sep 27, 2003 at 01:51:09AM -0400, Havoc Pennington wrote:
> > > On Sat, 2003-09-27 at 00:49, Havoc Pennington wrote:
> > > > 
> > > > The new gconf backend I wrote a year ago seems to use about 50% of the
> > > > memory of the current one
> > > 
> > > Or better, "gconftool-2 -R /" on my system (my .gconf has years worth of
> > > cruft in it) uses 53M with the old backend and 10.5M with the new. (the
> > > -R / means the whole gconf tree is cached in the daemon for a few
> > > minutes, so is the maximum possible mem usage)
> > 
> >   What is the difference technically speaking  ?
> > 
> The main performance issue with the old backend is building DOM trees.
> The new backend uses gmarkup but I don't think libxml vs. gmarkup is the
> speedup, the speedup is DOM vs. SAX-style.

  SAX is complex programming. There is also a maintainance issue with SAX
code. It allows very fast parsing but there are some drawbacks. Keeping the
DOM tree in memory doesn't sound a good idea, that's sure. There are
other appoaches possible, SAX is one, the xmlTextReader is another,
it is slower than pure SAX but the API is quite simpler to build and 
maintain code against it (Microsoft did some good work there).

> So you could move the new
> backend to libxml SAX-style API and still have the same advantage.

  Are you suggesting "if you want the gconf code back on top of libxml2
then do it yourself" ? Using "you" instead of "one" suggest this but this
could be some misunderstanding from my part ...
  I already stated that using a non-compliant parser wasn't a good idea
in general. But gconf as well as gmarkup is your code, so do what you 
prefer! It's just a bit of a shame that libxml2 wasn't used for your rewrite.
I find that surprising since you're trying to promote standardization
of tools, format and if possible codebases. It still puzzles me that I
have an easier job getting people outside of Gnome reuse libxml2 share
improvement and bugfixes, but that I have such a hard time within the
GNOME project.


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]