- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 04 Jun 2009 11:53:31 -0400
- To: João Eiras <joaoe@opera.com>
- CC: Jonas Sicking <jonas@sicking.cc>, Webapps WG <public-webapps@w3.org>
João Eiras 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. So the real question is how the overhead of comparing in the engine for every single attribute set matches up against the overhead of comparing in ECMAScript for the sets that are being listened to. On the other hand, it's not even clear to me how ECMAScript would make such a comparison. On a page where there's a listener for all attribute sets, of course, the answer is easy. Same for a page with no listeners (the common case!). If there are some listeners, it gets more complicated. I'm not quite sure which way the performance tradeoff lies here, to be honest. There is a real cost to doing the compare, but also real benefits to ignoring "no-op" sets, even internally (I seem to recall there were some situations where the compare we do right now actually helped Gecko performance). It might be good to gather some data on how common such no-op sets are in practice... -Boris
Received on Thursday, 4 June 2009 15:54:26 UTC