Re: Level 2 iterators

Miles Sabin wrote:
> The increase is in complexity in the big-oh sense ...
> that is, fixups (and even notifications of invalidation)
> have serious performance consequences, either for
> next/prevNode(), for tree mutation operations, or both.
> For those of us wanting to use the DOM on the server-
> side this is a serious issue, and would probably rule
> out the use of iterators in the same way that it now
> rules out the use of NodeLists. Worse still, it could
> also rule out the use of current or future APIs that are
> specified in terms of NodeIterators.

I tend to both agree and disagree.

I have both implemented and used NodeIterator in a server-side
application. I specifically did it in Java which, due to garbage
collector, imposes a penalty each time a NodeIterator is created. So,
flat out I did suffer a performance penalty.

However, if I had a choice between a live and a non-live iterator, I
would go with the live one. Using the live iterator required much less
code writing and code testing. In fact, the code worked first time out,
as opposed to having to test and correct the non-live iterator code.
That made a difference, even in an application that was to run on the
server-side.

While implementing the code, I learend some important issued. First, it
is possible to create a non-live iterator that is very efficient only
using the DOM API. That iterator can be made to work with any DOM
library very efficiently. The point I'm making is that there is no need
to extend Document in order to use non-live iterators, and an
application may provide and use it's own iterator for that matter.

On the other hand, implementing a live iterator required some common
calls between the DOM library and the NodeIterator implementation. That
also required that either Document or Node be extended with additional
factory methods. That is the type of iterator that the DOM specs should
cover, and the W3C is safe to assume such an iterator should be live.

Conclusion: the NodeIterator interface is not optimal, but the DOM
should define a live iterator, it is up to the application developer to
decide whether to use it or not.

Arkin


Assumption:  CPU performance is everything

Reality:  In some applications you may want to go the extra mile to make
sure the CPU is utilized to the max; but most of the time, if you can
develop it faster, test it less and run it more reliability, you have
gained performance and efficiency that surpasses raw CPU utilization.

Assumption:  Concurrent access is the issue

Reality:  Even if a single thread is manipulating the document, live
lists are easier to work with and require less logic on the application
side (less logic = less debug = shorter time to market). This is
especially true when using 3rd party documents that might have some
unknown affect on the document tree.

Assumption:  The DOM API should define all operations that work on a
document tree

Reality:  The DOM API should only define basic operations that can only
be provided by a DOM implementation, and not by 3rd party code. Anything
that can be written efficiently without relying on the DOM
implementation, can be provided by the application. Anything that can be
done differently (faster, or otherwise) in a specific application,
should be provided as an optional feature by the library provider.


> 
> Cheers,
> 
> Miles
> 
> --
> Miles Sabin                          Cromwell Media
> Internet Systems Architect           5/6 Glenthorne Mews
> +44 (0)181 410 2230                  London, W6 0LJ
> msabin@cromwellmedia.co.uk           England

Received on Thursday, 4 March 1999 22:00:49 UTC