xerces-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David_N_Bert...@lotus.com
Subject Re: DOM Performance
Date Thu, 01 Feb 2001 17:43:34 GMT

Andy Heninger wrote
> Miroslaw Dobrzanski-Neumann wrote
> > I wrote
> > > o  Associate all of the storage for a DOM document with the document
> > >    node object.  Applications would get document from the parser,
> > >    access it, and then explicitly delete it when done.  All Nodes and
> > >    strings would remain until the document was deleted.
> >
> > For a long time we (my company) had the similar memory problems. So we
> had
> > analysed how the memory is used in our code. It turned out that we
> needed some
> > kind of write once + random read optimization and taht the memory was
> bound to
> > some higher level object. Our solution was to use an allocator bound to
> the
> > object. It preallocates a big block and distributes it according to the
> > requests. The is reuse inside of the block. The whole block will be
> freed when
> > the object dies. The implementation of such allocator is very simply
> fast.
> >
> > This solution could also be applicable for DOM. In most cases the DOM
> Document
> > is build in a stright forward process with nearly no deletion or
> > modifications. Also write once, random read, free when the last node
> dies
> >
> This can even be extended to the point that the individual nodes and
> strings within a document are not individually deleted - just delete the
> heap without worrying about what it contains.  This would mean that the
> destructors for the individual nodes would never be invoked, but it saves
> a full traversal of the document, just to get rid of it.

Not running destructors for objects is a horrible thing as far as I'm
concerned.  You're violating one of the basic tenents of C++, that objects
which are constructed ought to be destructed.  OK, maybe for plain PODs
it's not a big deal, but you're talking about objects which presumably have
virtual functions, and have interfaces that support derivation.  I'm not
sure what the implications are for a program that does this, but it just
seems wrong to me.

Note that if you keep nodes in allocators like Xalan does, you don't need
to traverse the document to delete the nodes.  You just ask the allocators
to destroy them, and it explicitely runs the destructors for the individual
instances in a block, then releases the block.  You get good
locality-of-reference and you actually run destructors.

Of course, I don't feel the same way about arrays of XMLChs which are block
allocated -- just free the blocks and you're done.


View raw message