- 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