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

On Fri, Jan 22, 2010 at 5:11 AM, Anton Muhin <antonm@chromium.org> wrote:
> Good day.
>
> Currently DOM core 3 spec is somewhat inconsistent regarding if
> invocations of getElementsByTagName and alike must return a new
> NodeList or could cache this list.  For Document it's mandated for
> both getElementsByTagName and getElementsByTagNameNS, but for Element,
> it's only worded for getElementsByTagNameNS, but not for
> getElementsByTagName.  Maciej noticed as well difference between
> getElementsByTagName and other getElementsBy queries (see
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8792).  And word "new"
> is missing from ECMAScript bindings spec:
> http://www.w3.org/TR/DOM-Level-3-Core/ecma-script-binding.html
>
> 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.

I'm concerned about the GC-sensitivity of such behaviour (we might end
up snookering ourselves in a situation where specific GC behaviour
actually matters for compatibility).

How about the following compromise: these methods return a new object
each time, except if they are called with the same argument as the
previous invocation of the method? i.e. cache the last returned object
only. Would that be acceptable? It gives you a performance win in the
case where the author spins a loop using the same call over and over,
and is completely predictable.

Alternatively, if we need to cache more than that, how about blowing
away the cache with each spin of the event loop, so that anything in a
tight loop is cached (and _not_ subject to GC — this could be a
problem if the script calls one of these methods with 10000 different
arguments and sets properties on each one), but not beyond one task?
(i.e. don't share objects in calls across setTimeout)

For now for the objects in HTML5 I've gone with the first of these
suggested compromises.

-- 
Ian Hickson

Received on Saturday, 13 February 2010 11:19:01 UTC