Re: Mutation events - slowness examples

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