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

["Peter Jacobi" <pj walter-graphtek com>]

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