Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at