xerces-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Heninger" <an...@jtcsv.com>
Subject Re: DOM Performance
Date Thu, 01 Feb 2001 17:19:41 GMT
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 and
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.


Andy Heninger
IBM XML Technology Group, Cupertino, CA
heninger@us.ibm.com



Mime
View raw message