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

On 2/12/10 10:09 AM, Anne van Kesteren wrote:
> It would be interesting to know what exactly that test is. Optimizing
> for benchmarks is not always useful :-)

Point 1: Optimizing for benchmarks is sadly all that people report on. 
They don't even bother making up new benchmarks, so you can optimize to 
the small set of benchmarks currently in use.  So from a marketing 
standpoint, it is in fact highly useful.  This is very unfortunate.

Point 2: The reason that we (Gecko) initially added this behavior was 
that we ran into a number of sites doing things like:

   for (var x = 0; x < document.getElementsByTagName("foo").length; ++x) {
     doSomething(document.getElementsByTagName("foo")[x]);
   }

(a bit more obfuscated, but that's what it came down to).  Now granted, 
this was 8 years ago.  Maybe people are more careful now (though I doubt 
it).  This was not a benchmark, but real-world usage.

> Also, what happens with garbage collection? Say some isolated piece of
> code does:
>
> x = document.getElementsByTagName("x")
> x.p = 2
>
> ... and then later on some other piece of code does:
>
> y = document.getElementsByTagName("x")
> w("p" in y)
>
> Depending on whether or not x got garbage collected you would get a
> different result.

I think there are two separate parts to the current Gecko caching 
optimization:

1)  Avoid walking the DOM over and over.  This optimization is a must,
     imo.  This can be implemented without being detectable from script,
     at some cost in indirection and hence performance, by having
     different NodeList objects all sharing the same object which
     actually keeps track of the nodes.
2)  Avoid creating new JS objects for each call.  This optimization is
     in fact detectable by the above technique.  In Gecko's case this
     optimization is significant.  It looks like in Opera's and webkit's
     case it may be less so, based on my timings.  We would be unlikely
     to change this behavior while it continues to have the performance
     benefits is currently has for us.... but I'm willing to at least
     consider it if there are good enough reasons for it.

I should note that item #2 above depends heavily on GC policy, available 
RAM, etc, not just object-creation costs, in terms of how much it helps 
on any given page.  From a web programming point of view, less thrashing 
of the GC heap is generally a good thing if it's easy to do.

I should also note that right now if you set expandos on things like 
document.links or the .style of some node those expandos may or may not 
survive a GC in different browsers.  I believe the only place where 
expandos are really interoperable is on nodes and windows.  Certainly 
those are the only places where Gecko guarantees their survival, last I 
checked.

-Boris

Received on Friday, 12 February 2010 16:43:23 UTC