xerces-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph_Kessel...@lotus.com
Subject Re: DOM Performance
Date Fri, 02 Feb 2001 20:32:25 GMT

Freeing memory only when the entire document is released -- that's not all
that wierd an optimization, actually; it's one of the reasons IBM's C++
compiler supported multiple independent heaps. (Done with the data? Discard
the whole heap. No need to update the free list, so it's a lot faster.)
Wouldn't work well for documents which are mutated frequently over an
extended period,  obviously, since that produces leakage, but good for the
read-access-tweak-write-discard kind of cycle that you're proposing to
optimize for.

Note that this is _exactly_ why you want to have an abstract interface
layer -- no one DOM will ever be ideal for all applications, and you really
want the ability to switch between implementations to suit the needs of the
application without having to recode or recompile your libraries.



Re class hierarchy:  It looks to me like option 3 -- inheritance the DOM
interfaces, but not between implementations , and using delegation for
shared behaviors (TextImpl has-a NodeImpl which supports its node
behaviors) -- may look a bit ugly but is a good compromise between clean
architecture and clean implementation. The hybrid's also worth considering,
though there's something to be said for consistancy of design across the
different node implementations.



Mime
View raw message