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

For me performance-wise both approaches seem fine, but to get numbers I need
to run an experiment.

My main concern would be that rules are overcomplicated imho.  And I won't
be surprised if IE and FF would just ignore them.  But you understand all
those matters better than I do.

BTW, as the proposed change would reduce stress on GC, I don't quite see how
this could reduce compatibility (but life is often more complicated than I
can imagine.)

yours,
anton.

On Sat, Feb 13, 2010 at 2:18 PM, Ian Hickson <ian@hixie.ch> wrote:

> 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
>