Re: Mutation events - slowness examples

2009/6/7 François REMY <fremycompany_pub@yahoo.fr>

>  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
>
Remember that asyncronous events are not "events handled in a different
thread", are "events handled at the end of the current task (ie appended to
the task queue)", as required by HTML5 to keep javascript single threaded.
Of course this can cause an infinite sequence of events, ie an infinite
loop, but this already possible, without involving the DOM.
Giovanni