Re: Mutation events - slowness examples

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

> François REMY wrote:
> > There's cleary two factors that apply :
> > ==> Time needed to move from managed C++ to unmanaged JScript
> > ==> Time of JScript execution
> 
> You missed a third one: DOM event dispatch per se.
> 
> For example, on your test2, I see the following in a current trunk 
> Firefox build:
> 
> 10% of total time spent creating DOM nodes from the string.
> 40% of total time spent handling the insert internally
>     (creating the layout objects, etc).
> 45% of total time spent firing and handling the DOM event.
> 
> That last 45% breaks down as follows (all percentages are of total 
> testcase time):
> 
>    10% building up the event target chain and doing pre- and
>        post-dispatch handling of various sorts.
>     6% traversing that chain.
>     5% looking for listeners for this event on the various targets in
>        the chain.
>     6% setting up the right security context for the event dispatch.
>     8% creating the necessary JS objects (I have no idea why this
> takes
>        so long).
>     8% making the actual call into JS.
> 
> Note that about half the "event dispatch time" is used even if there
> is 
> no listener to dispatch to (though if there is really no listener we 
> optimize away the mutation event dispatch altogether)...
> 
> -Boris

Interesting. I may not be reading these results correctly - could you confirm these ratios:
- no listeners: 1x
- a DOMNodeInserted listener on the event chain: 2x (not counting listener execution time)
- a DOMNodeInserted listener NOT on the event chain: 1.5x

That doesn't seem so bad. If the 1.5x for the last case could be optimized to 1.1x then I would say just stick with the current spec. Can the dispatch algorithm check for listeners while building the event target chain and abort if there aren't any?

Received on Sunday, 7 June 2009 00:38:28 UTC