Why 'mutation events' are not so slow, relatively

From: "Boris Zbarsky" <bzbarsky@MIT.EDU>
Sent: Saturday, June 06, 2009 11:54 PM
To: "François REMY" <fremycompany_pub@yahoo.fr>
Subject: Re: Mutation events - slowness examples

> François REMY wrote:
>> Which number do you get ?
>
> I see Firefox doing a lot better in comparison to Opera than you do.

Installed add-ons can be the cause of the noticed slowdown.
I don't have many installed add-ons but I've noticed that add-ons is
the primary reason why FireFox is slow on many machines.

>
>> Maybe you get different data because :
>> * You're using Mac, and I'm using Windows
>> * You're using another build
>> * Your processor is faster
>> * You computer handle better the case we're focusing on
>
> Note that I was specifically talking about relative numbers, not the 
> absolute ones.

Yes, but with a 'newer' processor, optimisations have been done, so
the same code can be run much quicker than just the 'speed' improvement
of the processor. It's due to architecture change and the speed of internal
memory.

>> Anyway, the real number is not very important. Wat is really important
>> is how problematic it is (currently, I see no reason why mutation events
>> should be deleted; specific optimisations and filtering possibilities
>> would solve the problem raised by other members, I think).
>
> You don't think a 3-10x slowdown (from your own data; my data agrees on 
> the general range) is problematic?

I don't think they are problematic because the data shows that it can be 
translated
into a x2 / x2.5 range. Which is not a problem if we consider that the time 
used
by adding an element to the DOM is really small, relatively to the time the 
UA
need to render it.

As you may have noticed, we speek about change of speed less an a 10th of
second. Even with a whole page's loading, we can't have a slowdown of more
than a second, which is acceptable (because no site would rely on a mutation
event before the page load).

Another thing we need to look at : What would be the time lost by the 
browser
if we did the 'style' change (in my first example) by using a setInterval 
and a filtering
of elements to find 'newly' inserted elements ? This is currently the best 
way to do
the same thing without using mutation events.

    * A first render is done with bad style.
    * The timer take time even if no action has been done
    * We need to walk the whole DOM to math new elements
    * We need to apply our change
    * A second render need to be done

If you add to this that webmasters don't need the event get fired for every 
element but
only for certains elements (based on XPath/CSS filtering), you may notice 
the time
lost is not so important.

> -Boris

Received on Sunday, 7 June 2009 08:48:36 UTC