- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 25 Jun 2009 00:17:46 -0700
- To: Sean Hogan <shogun70@westnet.com.au>
- Cc: François REMY <fremycompany_pub@yahoo.fr>, www-dom@w3.org, "Michael A. Puls II" <shadow2531@gmail.com>
On Wed, Jun 24, 2009 at 11:53 PM, Sean Hogan<shogun70@westnet.com.au> wrote:
> Jonas Sicking wrote:
>>
>> On Wed, Jun 24, 2009 at 8:52 PM, Sean Hogan<shogun70@westnet.com.au>
>> 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.
>>>
>>> Conclusion (tentative):
>>> The non-JS overhead of DOMAttrModified events is irrelevant to the UX,
>>> being
>>> well under 1ms per event.
>>
>> I'm not sure I follow, 25ms -> 120ms seems quite relevant.
>
> 95ms for 1024 events. That's less than 0.1ms per event, which is why I would
> say irrelevant to user-experience.
> How would you define "irrelevant to the user experience" and do you think
> any alternative could do significantly better?
I don't really have any data on how much attribute-setting performance
sensitive applications are doing, or will be doing in 5 years. So
while it's 0.1 ms per event, you have to multiply that by an unknown
number of events.
So to me it's the percentage-wise change that is interesting. Unless
we have reason to believe that the whole operation happens rarely
enough that performance in general just isn't an issue at all.
/ Jonas
Received on Thursday, 25 June 2009 07:18:53 UTC