- From: Sean Hogan <shogun70@westnet.com.au>
- Date: Fri, 26 Jun 2009 11:32:44 +1000
- To: François REMY <fremycompany_pub@yahoo.fr>
- CC: www-dom@w3.org, "Michael A. Puls II" <shadow2531@gmail.com>
Sean Hogan wrote:
> 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.
>
I've updated test5 to account for the browser handling multiple
attribute modifications in one batch.
The new test (attached) modifies the title on 256 populated div elements.
The contents of the div are styled based on the title. eg
div[title="After"] ul li { ... }
Results (approx)
Firefox: 48ms - > 79ms
Opera: 40ms -> 50ms (both times vary by up to 30ms in no discernable
pattern)
I'll try to set up some test pages on my web-site in the next week.
> Conclusion (tentative):
> The non-JS overhead of DOMAttrModified events is irrelevant to the UX,
> being well under 1ms per event.
I still agree with this, but...
> 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.
>
>
In scenarios where MutationEvent handlers don't force page re-layout the
browser can reduce the cost of page re-layout by handling several DOM
mutations in one shot.
Received on Friday, 26 June 2009 01:33:41 UTC