On Feb 12, 2010, at 5:05 AM, Anne van Kesteren wrote:
On Fri, 12 Feb 2010 12:51:03 +0100, Maciej Stachowiak
<m...@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 <ant...@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
