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

Re: Mutation events - slowness examples

From: Sean Hogan <shogun70@westnet.com.au>
Date: Thu, 25 Jun 2009 13:52:52 +1000
Message-ID: <4A42F494.8040900@westnet.com.au>
To: Fran├žois REMY <fremycompany_pub@yahoo.fr>
CC: www-dom@w3.org, "Michael A. Puls II" <shadow2531@gmail.com>
I've made a couple of tests pages for DOMAttrModified (attached).

test4.html modifies (1024 times) the title on an empty div and measures 
execution time without / with DOMAttrModified listener.

test5.html modifies (16 times) the title on a populated div.
Additionally, the contents of the div are styled based on the title. eg 
div[title="After"] ul li {...}

The repetition counts are chosen to get reasonable timing data.

Results (approx)
test4:
Firefox: 25ms -> 120ms
Opera: 35ms -> 120ms

test5:
Firefox: 43ms -> 48ms
Opera: 50ms -> 50ms

Note: Safari doesn't trigger DOMAttrModified events.

Conclusion (tentative):
The non-JS overhead of DOMAttrModified events is irrelevant to the UX, 
being well under 1ms per event.
In the case when modifying an attribute results in a change in styling, 
this overhead might even be significantly less than the cost of updating 
page layout.



Sean Hogan wrote:
> I've made some changes to make this demo more realistic:
> 1. use document.body.clientHeight to force a rendering update.
> 2. insert HTML with more complex layout. The original HTML 
> "<span>A</span>" repeated 1024 times had a extreme ratio of 
> DOMNodeInserted events to layout complexity.
> 3. make the insertion point 5 DIVs deeper in the document.
>
> My results (approximately):
> Firefox: 40ms -> 50ms
> Webkit: 28ms -> 31ms
> Opera: 35ms -> 45ms
>
> This is still a shallow and wide HTML fragment being inserted - 128 
> DOMNodeInserted events for not much content.
> In the real-world I would imagine that the non-JS overhead of 
> DOMNodeInserted events is almost always irrelevant to the UX.
> The JS cost will be incurred no matter what form of handling is provided.
>
> The test-page is attached.
> I'll endeavour to provide realistic tests for other Mutation Events in 
> the next few days.
> Sean
>
>
> Fran├žois REMY wrote:
>> Result on my computer :
>>
>> Test 1 (something is done by JScript)
>>    IE:                     Not Applicable
>>    FireFox:           30 > 160 (x5 or +130)
>>    Chrome:           5 > 60 (x10 or +55)
>>    Opera:              15 > 45 (x3 or +30)
>>
>> Test 2 (nothing is done by JScript, just for comparaison)
>>    IE:                     Not Applicable
>>    FireFox:           30 > 80 (x3 or +50)
>>    Chrome:           5 > 40 (x8 or +35)
>>    Opera:              15 > 30 (x2 or +15)
>>
>> There's cleary two factors that apply :
>> ==> Time needed to move from managed C++ to unmanaged JScript
>> ==> Time of JScript execution
>>
>> These two factors are clearly dependant of the browser. In FireFox, 
>> it seems there's clearly a problem with that.
>> Others browsers react smartly enough.
>>
>> Regards, Fremy
>>
>> --------------------------------------------------
>> From: "Michael A. Puls II" <shadow2531@gmail.com>
>> Sent: Saturday, June 06, 2009 3:49 PM
>> To: <www-dom@w3.org>
>> Subject: Mutation events - slowness examples
>>
>>> Are there any example pages of mutation events being really slow 
>>> and  causing things to lag?
>>>
>>> Are they always slow in every browser?
>>>
>>> -- 
>>> Michael
>>>
>>
>
> ------------------------------------------------------------------------
>



Received on Thursday, 25 June 2009 03:53:50 GMT

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