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

Re: Mutation events - slowness examples

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 25 Jun 2009 00:40:04 -0700
Cc: Jonas Sicking <jonas@sicking.cc>, François REMY <fremycompany_pub@yahoo.fr>, www-dom@w3.org, "Michael A. Puls II" <shadow2531@gmail.com>
Message-id: <88C7A2F5-B578-4307-ACFB-913EE4ECC59D@apple.com>
To: Sean Hogan <shogun70@westnet.com.au>

On Jun 25, 2009, at 12:25 AM, Sean Hogan wrote:

>>
>> 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.
>>
> That doesn't answer either question.

Effect on the user experience can't be determined based on the  
absolute time cost increase of a single operation. So that question  
isn't one that can easily be tied directly to the experiment. I agree  
with Jonas that, when it comes to microbenchmarks like this, it's the  
proportional cost, not the absolute cost of the operation, that is  
most informative. Making all basic DOM mutating operations 2-4x slower  
certainly sounds like it has the potential to degrade user experience.  
In general, making anything 4x slower should set off alarm bells  
unless there is clear proof that the operation is both very fast and  
extremely rare.

As an analogy, consider the possibility of slowing down every CPU  
floating point multiplication by .1ms. Some applications would be  
largely unaffected, but the ones that multiply a lot would obviously  
suffer an unacceptable slowdown, because .1ms is a huge amount of time  
relative to the normal execution time of an instruction.

100ms in aggregate is a high cost, and 1000 DOM mutations is a low  
enough number that it's not implausible it will be hit, particularly  
since 1000 DOM operations are so fast without the mutation event  
overhead. Consider also the cost in terms of power consumption. Even  
if that extra 100ms is spread out over several seconds, it could still  
be a big hit in terms of battery life.

In conclusion, I think the data presented shows the performance  
characteristics of mutation events to be unacceptable in current  
browsers to endorse them as a common technique.

Regards,
Maciej
Received on Thursday, 25 June 2009 07:40:51 GMT

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