Re: Mutation events replacement

On 7/6/11 4:27 AM, Dave Raggett wrote:
> How does that scale to the case where you set the observer on the
> document or on a div element acting as a contained for content editable
> content? If I am not mistaken you would have to keep a copy of the
> document, or of that div element respectively, and keep it in sync with
> all of the mutations, which sounds like a major performance hit, and
> something you don't need to incur with the current DOM mutation events.

Oh, you _do_ incur a major performance hit with current mutation events 
if you watch attribute mutations, precisely due to the need to save the 
pre-mutation values.  You just push the performance hit off on the 
browser core.

And before you say that it can do this more efficiently, that's only 
true if you're interested in the previous value of _all_ attributes.  I 
realize your particular use case is.  But lots of others are not. 
Unfortunately, the browser has no way to tell which attributes on which 
elements the mutation event really cares about, so all mutation event 
consumers take the same performance hit.  Which leads to the common 
recommendation to not use attribute modification mutation events at all, 
because, for example, they make your jQuery animations dog-slow.

Again, I realize this is not a problem for you because of your 
particular use case of mirroring the entire DOM.  But let's not pretend 
there's no performance hit now or that the performance hit with a 
different setup would always be more than what we have now.

-Boris

Received on Wednesday, 6 July 2011 12:38:42 UTC