W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2009

Re: Mutation events - slowness examples

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Sun, 7 Jun 2009 14:33:37 +0200
Message-ID: <C0D9EF8BC34C4E4BB39ECD91EDB99C54@FREMYCOMPANY>
To: "Sean Hogan" <shogun70@westnet.com.au>, "Boris Zbarsky" <bzbarsky@MIT.EDU>
Cc: <www-dom@w3.org>
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
Received on Sunday, 7 June 2009 12:34:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:00 GMT