Re: Mutation events replacement

On Thu, Jun 4, 2009 at 9:02 AM, Joćo Eiras <joaoe@opera.com> wrote:
>>> The overhead of comparing the previous with the new value inside the
>>> engine is a fragment of the overhead of calling an ecmascript callback
>>> and doing the same comparison in ecmascript.
>>
>> For a given operation that has a callback listening, yes.  But most
>> operations do not have a callback listening, as it happens.
>
> You are thinking along the following algorithm
>
> if new_value != old_value then
>  foreach listener in listeners
>    call listener
>
> I'm thinking in the following
>
> if has_listeners
>  if new_value != old_value then
>    foreach listener in listeners
>      call listener
>
> So, unless there are listeners (which is a very simple instruction to
> evaluate), there is penalty in checking whatever needs to be checked.
> And this is what UAs do, considering there is currently a big visible
> performance tradeoff when one adds no-op listeners (yes, event
> capturing/bubbling also affects it)

The goal here is to create an API that is performant even when there
are listeners, so I don't want to rely on optimizations for when there
are no listeners.

So I ran some numbers. About 10-20% of all attribute setting is for
the same value that the attribute already has. That's quite higher
than I had expected. I went to some news sites, some mozilla.org
pages, gmail and google calendar.

One solution would be to leave it undefined. This way the
implementation could do whatever is most performant. For example, in
gecko, setting the style attribute would require a slow serialization
of style data to determine if a change occurred, whereas setting a
data-* attribute only requires a quick string compare.

But I'm generally uneasy to leave things as undefined. It seems
unlikely that people would rely on events not firing too often, but
I'm sure someone out there will by accident (there's lots of crazy
things out there).

/ Jonas

Received on Thursday, 4 June 2009 23:50:14 UTC