- From: Sean Hogan <shogun70@westnet.com.au>
- Date: Thu, 25 Jun 2009 13:52:52 +1000
- To: François REMY <fremycompany_pub@yahoo.fr>
- CC: www-dom@w3.org, "Michael A. Puls II" <shadow2531@gmail.com>
- Message-ID: <4A42F494.8040900@westnet.com.au>
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
>>>
>>
>
> ------------------------------------------------------------------------
>
Attachments
- text/html attachment: test4.html
- text/html attachment: test5.html
Received on Thursday, 25 June 2009 03:53:50 UTC