W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: Allow to return same NodeList object for queries like getElementsByTagName, getElementsByClassName and getElementsByName

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 12 Feb 2010 05:13:57 -0800
Cc: Anton Muhin <antonm@chromium.org>, public-webapps@w3.org
Message-id: <5A981280-2C94-4140-869D-9C794E5E13B6@apple.com>
To: Anne van Kesteren <annevk@opera.com>

On Feb 12, 2010, at 5:05 AM, Anne van Kesteren wrote:

> On Fri, 12 Feb 2010 12:51:03 +0100, Maciej Stachowiak  
> <mjs@apple.com> wrote:
>> On Feb 12, 2010, at 3:47 AM, Maciej Stachowiak wrote:
>>> On Feb 12, 2010, at 3:19 AM, Anne van Kesteren wrote:
>>>> On Fri, 22 Jan 2010 14:11:40 +0100, Anton Muhin <antonm@chromium.org 
>>>> > wrote:
>>>>> Is it possible to allow caching for those cases?  Firefox caches  
>>>>> those
>>>>> node lists for a long time (Maciej found the related bug
>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=140758).  IE8  
>>>>> caches as
>>>>> well.   Opera, Safari and Chrome do not.
>>>>
>>>> Sorry for the somewhat late reply. We'd prefer not to change the  
>>>> specification here and keep the requirement. We're afraid of  
>>>> potential hard to detect incompatibility bugs if you sometimes  
>>>> cache and sometimes don't. We're also not convinced that you  
>>>> cannot get the performance win by other means.
>>>
>>> Since Firefox and IE both cache, how would it create compatibility  
>>> bugs for other browsers to do so as well? I think we should remove  
>>> the requirement unless Firefox and IE are willing to change their  
>>> implementations.
>
> I would hope they fix their bugs in due course, yes. Specifically  
> leaving the behavior undefined seems like a bad idea. We know that  
> from other areas.

It's clear from the Mozilla bug cited above that this behavior was  
added intentionally after first implementing per spec. Jonas also said  
earlier that he'd like to make the behavior conforming. I would not  
assume they are willing to change their behavior unless they actually  
say so. We are strongly considering adding this behavior to WebKit,  
which would leave Opera as the only browser following the letter of  
the spec.

>> In addition, I should mention that likely the only observable  
>> difference is in setting custom ("expando") properties. If you make  
>> two equivalent requests for a NodeList, setting a property on one  
>> will show up on the other only in the case where there was caching.  
>> However, I think use of expando properties on NodeLists is  
>> unlikely. Sacrificing a lot of performance for a marginal  
>> hypothetical improvement in predictability of behavior does not  
>> seem like a good tradeoff.
>
> Is it really a lot of performance? Our developers are not that  
> convinced.

A patch that made the change in WebKit was measured as a 20% speedup  
on the Dromaeo DOM Core tests in both Safari and Chrome. Calling these  
query methods is only a small fraction of the test, so this implies a  
much larger speedup to the case where getElementsBy* is called in a  
loop. Note also that this involved two different JavaScript engines so  
it's unlikely to be a quirk specific to one engine. The Gecko bug  
cited above also shows dramatic speedups on various tests.

> Also it has been suggested to me that just-in-time optimizations  
> might not work well if different users start polluting the same  
> object (if nodelists are shared).

I'm not sure what that sentence means.

Regards,
Maciej
Received on Friday, 12 February 2010 13:14:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:37 GMT