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


 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 ?


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.


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)?

Peter Jacobi

xml mailing list, project page
xml gnome org

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]