Re: Mutation events - slowness examples

----- "Boris Zbarsky" <bzbarsky@MIT.EDU> wrote:

> Sean Hogan wrote: 
> > - a DOMNodeInserted listener NOT on the event chain: 1.5x
> 
> Not quite; see below.
> 
> > That doesn't seem so bad.
> 
> It does to me, for several reasons:
> 
> 1)  The "no listeners" part will keep getting smaller; as you can see
>      by comparing to Chrome and Opera, Firefox could improve this
>      part quite a bit.
> 2)  The testcase has a very shallow DOM.  The "no listeners" part
>      doesn't really depend on DOM depth much.  Event dispatch is O(N)
>      in depth of DOM, pretty much by definition.
> 3)  Even a 2x slowdown (or heck, even 1.5x) is huge.
> 

It's only huge if it noticeably affects the UX. 
This example arguably proves that it does not: 1024 DOMNodeInserted events and it's only just on the threshold of user awareness - 100ms. 
And this test doesn't even include the time for rendering - I've done some primitive testing and for a smaller number of inserted nodes (say 100) the rendering takes longer than the event dispatch. 

> > If the 1.5x for the last case could be optimized to 1.1x then I
> would say just stick with the current spec.
> 
> The main issues for me with the current spec from my point of view are
> not the perf issues when you do use mutation events, necessarily, but
> the performance impact on the no-event case forced by possible 
> synchronous firing of events, the complexity of not introducing
> security 
> bugs while implementing mutation events, and the fact that mutation 
> events aren't as useful as a non-reentrant system could be.  There are
> plenty of other things a web page can already do to fall into "slow 
> case" paths in rendering and scripting engines, and some of these are
> more widespread than mutation listeners...
> 
Agreed. I guess by current spec I mean using DOM Events as opposed to some new handling scheme. But couldn't we just change the spec so that Mutation Events are asynchronous? Is anyone relying on them being synchronous?

> > Can the dispatch algorithm check for listeners while building the
> event target chain and abort if there aren't any? 
> 
> It already does in Gecko, which is why in practice the overhead for
> the 
> "mutation listener not on parent chain" case is not quite the 1.5x
> cited 
> above.  It'd still be O(N) in depth of DOM, of course.
> 

In fact, my testing indicates there is no time difference between "DOMNodeInserted listener not on parent chain" and no DOMNodeInserted listener. Do you have examples that demonstrate otherwise?

Received on Sunday, 7 June 2009 12:01:48 UTC