The Deferred DOM (was Re: REDOM Design discussion.)

[Arnaud Le Hors <le...@us.ibm.com>]

[ message first sent on Friday which never made it to the list before ]

Ryan Schmidt wrote:
> 
> The DeferredDocumentImpl
> class is a perfect example of this - I spent hours trying to figure out
> what was going on with that class...very aggravating.

I agree this project is suffering from a serious lack of documentation
on the internals. That's what happens when you don't have enough
resources and you're constantly under pressure to provide more features.
It's not an excuse, just a fact.
But there is no point in wasting your time like that, you should have
asked. It's not that complicated actually. 

The idea of the Deferred DOM is to lazily create the DOM structure.
Instead of creating all the nodes up-front, the parser creates a more
compact structure (a set of int arrays) and only creates a shallow DOM
structure that points back to the compact structure. Then as the DOM
structure is traversed, the information from the compact structure is
fluffed up into the DOM.

Note that if you actually traverse the whole tree you don't really gain
anything. On the contrary, every node is a little bigger (due to the
reference to the original structure). On the other hand, if you only
access a few nodes, it's a big win.
-- 
Arnaud  Le Hors - IBM Cupertino, XML Technology Group

Re: The Deferred DOM (was Re: REDOM Design discussion.)

[Ryan Schmidt <ry...@cpsc.ucalgary.ca>]

Arnaud Le Hors wrote:
> > The DeferredDocumentImpl
> > class is a perfect example of this - I spent hours trying to figure out
> > what was going on with that class...very aggravating.
> 
> I agree this project is suffering from a serious lack of documentation
> on the internals. 
<snip>
> But there is no point in wasting your time like that, you should have
> asked. It's not that complicated actually.
> 
> The idea of the Deferred DOM is to lazily create the DOM structure.

Agreed, it's not that complicated. I understood the purpose of the int
arrays
quickly. The hours I spent trying to figure out what was going on were
spent
in the debugger, inspecting the int arrays and watching what happened at
each
step of the deferred-expansion. This was the point I was trying to
get across. Having internals documentation is nice, but having methods
that
would dump out the internals would be _far_ more useful, IMHO. Takes
less
time to write, and easier to keep up to date (compile errors sort of
force
that on you). I find that being able to watch what is going on (usually)
increases
my understanding much more then reading about what is going to happen.

Anyway, enough of that. This should probably be in a separate
message...but
how would I go about timing/benchmarking something like, say, ints vs
Strings vs
RecyclableStrings. I've been writing a simple 'RecyclableString'
implementation,
and I'd like to know how it compares, but I'm not exactly sure how to go
about
this. 

-RMS