Re: Thought on future of XMLC

This is a very interesting idea.  Looking at some benchmarking before
prototyping would be important.

However, it's not clear to me that this is going to be an improvement.  The
lazydom doesn't track if a subtree is expanded and a subtree can be expanded
without it's parent being expanded.  A mechanism would have to be created to
track it without adding much overhead.

Hmm, maybe this isn't so hard.

Add a boolean array, parallel to LazyDocument.fExpandedNodes the indicates if
a node or any of it's children are expanded, say fSubtreeExpanded .  When a
node is expanded, walk backwards up the tree (without expanding the tree),
setting the fSubtreeExpanded flag for each parent.  This stops when a node
with fSubtreeExpanded set is found.

Mark


David Li <david@xxxxxxxxxxxxxxxxx> writes:
> > Also you would need more information from the parsing process: When 
> > the DOM is created you would need to store the beginning offset and 
> > ending offset (from the original HTML string) within the DOM node.
> 
> There is no reason to do this. The information is already in the 
> subtree of the node. However, using one long string and keep index into 
> it may not be a bad idea. This would only increase the memory foot 
> print by the size of file * 2 + 4 bytes * number of nodes. Hmm... looks 
> more feasible now.
> 
> This would be some optimization to performance of LazyDOM. Can we start 
> establishing some benchmark number for DOM so we know how much we gain 
> from using different DOM implementation.