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
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.
Received on Sunday, 7 June 2009 12:34:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:37 UTC