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

Re: Mutation events - slowness examples

From: Sean Hogan <shogun70@westnet.com.au>
Date: Thu, 25 Jun 2009 20:59:28 +1000
Message-ID: <4A435890.2020007@westnet.com.au>
To: Maciej Stachowiak <mjs@apple.com>
CC: Jonas Sicking <jonas@sicking.cc>, François REMY <fremycompany_pub@yahoo.fr>, www-dom@w3.org, "Michael A. Puls II" <shadow2531@gmail.com>
Maciej Stachowiak wrote:
> 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.
This argument also applies to attribute selectors in CSS.
In fact, one of the test pages (test5.html) demonstrates a scenario 
where the cost of page re-layout incurred by attribute selectors is 10x 
the non-JS cost of DOMAttrModified.
The cost of page re-layout might be mitigated by the browser being able 
to handle a batch of DOM mutations in one hit.

> 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.
See above.
> 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.
See above.
> 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.

See above. There are scenarios where the page reflow costs of DOM 
Mutation far outweigh the non-JS event handling. I have provided test 
pages to demonstrate this, but neither you nor Jonas have referred to 
them at all.
Received on Thursday, 25 June 2009 11:00:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:55 UTC