Re: Mutation events - slowness examples

On Thu, Jun 25, 2009 at 3:59 AM, Sean Hogan<shogun70@westnet.com.au> wrote:
> 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.

An important distinction is that there are alternatives to DOM
mutation events that provide the same benefit, without the high cost.
See the thread I started recently regarding alternative to mutation
events. At least in gecko, that API can be implemented with basically
zero overhead cost.

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

I know I haven't kept up with all the examples people have posted (and
I've likely forgotten a few of the ones I did see). Would be great if
you could provide references.

However note that the fact that there are examples where DOM Mutation
events don't have overhead, does not detract from the fact that there
are examples where they do. I'm also concerned about situations where
Nodes that are disconnected from the Document is mutated. And about
when nodes that are in an undisplayed part of the document is mutated.
And when Documents that aren't displayed are mutated (such as
documents from XMLHttpRequest or DOMParser). And when attributes that
don't affect layout are mutated.

/ Jonas

Received on Friday, 26 June 2009 00:03:39 UTC