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

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

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