Re: [D3E] Possible Changes to Mutation Events

Maciej Stachowiak <mjs@apple.com> wrote:

> On Jul 16, 2008, at 5:00 PM, Stewart Brodie wrote:
> 
> > Maciej Stachowiak <mjs@apple.com> wrote:
> >>
> >> On Jul 16, 2008, at 2:03 PM, Stewart Brodie wrote:
> >>
> > > > I agree with all that, but it's not the whole story, because making
> > > > this change has potentially severe consequences for memory usage if
> > > > you start moving large subtrees around within a document.  Just how
> > > > long is the event queue allowed to get?
> >>
> > > It will only grow without bound if every mutation event handler in
> > > turn modifies the DOM itself, or if a compound DOM operation is
> > > unbounded.
> >
> > Unbounded queueing is a real concern.  Having said that, the current
> > situation is that we have unbounded recursion, which is equally
> > unacceptable, although the recursion depth is at least defined by the
> > number of recursive calls made by the event listeners, whereas the queue
> > length is dependent on the number of nodes in the affected subtree,
> > which is likely to be substantially greater.
> 
> Can you describe a plausible scenario where growth of the mutation event
> queue would be a significant issue? You've said repeatedly you are worried
> about it but have not given an example of when this might happen. Are you
> talking about the kind of programmer error that results in an infinite
> loop?

[Many apologies for the delayed reply]

The worst case I can think of is Node.replaceChild() where the removed child
is a large subtree and the new child is a large subtree that's attached
somewhere else in the document.  This sort of content is easily feasible in
the sort of UI applications that we have to support (for example, a TV
electronic programme guide), and yet the memory we have available is
severely constrained.

If each subtree contains just 100 nodes, that's 303 events to be queued.
Even if the new subtree is not attached, that's still 203 events.  What
happens if we have no memory left in which to queue these events?

Concentrating on the removal side, currently, I have to queue 0 events, and
I can optimise away DOMNodeRemovedFromDocument completely, usually. However,
I have to ensure that the detached node and its parent are still valid after
the dispatch of DOMNodeRemoved.  With these changes, I could only optimise
away the events if *neither* DOMNodeRemoved or DOMNodeRemovedFromDocument
have any listeners.  Sure, the DNRFD events would get optimised out at the
point of dispatch, but I've had to store a whole load of information in the
meantime.

The alternative would be to queue a promise to generate the event for every
node in the subtree, but that promise would end up being fulfilled based on
the state of the tree after DOMNodeRemoved listeners had been executed.
However, it would reduce the likelihood of memory problems dramatically.


-- 
Stewart Brodie
Software Engineer
ANT Software Limited

Received on Monday, 21 July 2008 15:14:33 UTC