From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-07-12 07:28:38
Phil Endecott wrote:
> I have just dug out an old email that I wrote to the xmlwrapp list in
> 2004. I had observed that xmlwrapp, which is a C++ wrapper around
> libxml2 with much in common with Stefan's proposal, had an overhead of
> about 150 bytes per node. I had been getting binary data from a
> database (with negligible space overhead compared to a C++ struct),
> converting it to in-memory XML and then converting that to HTML or SVG
> using XSLT. The in-memory XML was terribly bloated to the extent that
> it was the bottleneck in the system, for a couple of reasons.
...
> The view I'm coming to is that I'd prefer an XML class with enough
> template parameters to make these sorts of issues resolvable by the
> user, depending on the requirements of their application:
...
After such an experience my thoughts would be less oriented towards changing
the XML in-memory class and more towards refactoring the application to not
build the entire XML document in memory. This obviously wouldn't be possible
if your next processing phase demands an in-memory XML as input; but if it
does, it's possible that you wouldn't be allowed to change it anyway; you'll
have to live with whatever template parameters have been picked by its
author. If, on the other hand, the HTML/SVG backend takes an
element_iterator range, you'll be able to feed it on demand without ever
constructing the whole tree. Of course this would likely mean no XSLT. Doing
an XSL transform on a "virtual" document would require an abstract node
interface that you implement on top of your existing data to provide an XML
view for it.