Re: Mutation events - slowness examples

From: "Sean Hogan" <shogun70@westnet.com.au>
Sent: Sunday, June 07, 2009 2:01 PM
To: "Boris Zbarsky" <bzbarsky@MIT.EDU>
Cc: <www-dom@w3.org>
Subject: Re: Mutation events - slowness examples

> 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. 

I agree with you here.

>> 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?

Yes, they should be synchronous. 

If they're not we can have something like that:

      Thread 1
     Event Thread 1
     Event Thread 2
     
      Attribute X changed to '1'
      
      
     
       
     Start running the listeners
      
     
      Attribute X changed to ‘2’
      
      
     
       
      
     Start running the listeners
     
       
     The value is ‘2’
      
     
       
      
     The value is ‘2’
     


==> The value '1' was never trapt by the handlers
==> The value '2' was trapt 2 times

==> If the handler modify the value of X, you will have an infinite number of threads opened (each modification invokes a new thread for the event handling, which invoke a modification, which invokes a new thread for the event handling, ...); if you maintain all these operations in one thread, you'll be able to stop the infinite loop because the stack will become too great.
 
Regards,
Fremy