Re: [xml] Re: [xslt] libxml3 (C++ Wrappers, Performance Paranoia)

[Daniel Veillard <veillard redhat com>]

  Okay,

 I clearly can't keep-up with all development wishes, Peter would you
like to drive this effort ? This would include the following steps:
   - make a new module in Gnome CVS called libxml3
   - give you (or another maintainer) commit rights on it
   - start hacking on that tree
   - integrate patches from the libxml2 branch
 As the IETF motto I believe in "rought consensus and running code",
and I don't see how I could at the moment maintain running code, I think
there is at least a few individual on this list ready to work on it, and
I can't act as the coordinator, so to avoid loosing time I suggest to
get the resources needed fork now and don't wait for me.
 Among the things to look at in libxml3 is the API for a shared access of
the private field of nodes,

 So Peter do you want to drive this, or otherwise is there any volunteer ?

Daniel

On Tue, May 14, 2002 at 09:34:59AM +0200, Peter Jacobi wrote:
> Hi Daniel, All,
>  
> >   To some extent. Libxslt is fast in part because it doesn't
> > go through a convoluted DOM like API to access the tree.
> > The goal is to allow building (and if needed garbage collecting)
> > the tree on access from a different representation (DB, flat file,
> > etc ... you name it !).
>
> I'm all for a lightweight libxml3! In fact most of my speculation on this is 
> caused by performance issues.
>
> > > to (nearly) all of libxml3 itself. So that about 2000 uses
> > > of "node->next" (et al) would be replaced 
> > > with "getnext(node)".
> >
> >   At that point I'm afraid this would be a bit premature, 
> > however I would be interested in informations about the 
> > speed penalty this would generate (hey I could be wrong !)
>
> Even if this doesn't expand to macro, it is an easily predicted 
> branch and return which will you cost about 10 cycles. So I
> don't see a bottleneck here.
>
> > > The default tree implementation can implement these
> > > as macros, so that nothing changes in that case. But
> > > we can have plugable tree implementations.
> >
> >   yup
>
> And, with plugable tree implementation, the real savings
> are reachable:
>
> - an implementation optimized for read-only access, which
> can eliminate most of the heap memory allocations
>
> - an implementation using C++ STL if libxml3 is used from
> C++, which eliminates the copying, allocations and frees
> necessary in libmxml2 C++ wrappers
>  
>
> Whereas the patch needed for libxml itself would be large but finite, there 
> is the problem, what to do with all the legacy code, using
> "node->next" everywhere, as Igor pointed out.
>
> Should the author be expected to globally search and replace
> to "getnext(node)" or should there be a compatibility layer which
> casts all these shiny new handles back to xmlNode* (in case of
> the default tree implementation, obviously it won't work with another
> implementation plugged in)?
>
> Regards,
> Peter Jacobi
>
> _______________________________________________
> xml mailing list, project page  http://xmlsoft.org/
> xml gnome org
> http://mail.gnome.org/mailman/listinfo/xml

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/