[Webkit-unassigned] [Bug 33696] let's cache nodelists instead of dynamicnodelist::cache

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=33696





--- Comment #25 from anton muhin <antonm at chromium.org>  2010-02-02 01:33:35 PST ---
(In reply to comment #24)
> (In reply to comment #23)
> > (In reply to comment #22)
> > > (In reply to comment #21)
> > > > Mozilla has been returning the same NodeList from getElementsByTagName for a
> > > > long time:
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=140758
> > > > 
> > > > It's not clear if they know this technically violates the DOM Core spec, but it
> > > > does seem to imply the behavior is safe for Web compatibility.
> > > 
> > > Yep, I verified that Mozilla caches node lists as well.
> > > 
> > > And regarding standard.  There is funny inconsistency. If you take a look at
> > > Document wording it says new, but for Element wording it doesn't say new for
> > > getElementsByTagName, but does for getElementsByTagNameNS.
> > > 
> > > Answering another question: gain is due to reduced pressure on GC, so producing
> > > new JS wrappers would most probably kill the optimization.  And Mozilla bug you
> > > spotted says roughly the same.
> > > 
> > > So the conclusion is we are waiting for changed HTML5 spec?
> > > 
> > > If yes, any ETA?
> > > 
> > > And thanks a lot for very interesting investigation of the question.
> > 
> > I think we should suggest a change or erratum to the DOM Level 3 Core spec. It
> > seems like even if returning a new object was intended, it's not what
> > implementations do. I suggest mailing public-webapps at w3.org to start a
> > discussion. Or I can do it if you'd rather not deal with the standards groups.
> 
> Mac(In reply to comment #23)
> > (In reply to comment #22)
> > > (In reply to comment #21)
> > > > Mozilla has been returning the same NodeList from getElementsByTagName for a
> > > > long time:
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=140758
> > > > 
> > > > It's not clear if they know this technically violates the DOM Core spec, but it
> > > > does seem to imply the behavior is safe for Web compatibility.
> > > 
> > > Yep, I verified that Mozilla caches node lists as well.
> > > 
> > > And regarding standard.  There is funny inconsistency. If you take a look at
> > > Document wording it says new, but for Element wording it doesn't say new for
> > > getElementsByTagName, but does for getElementsByTagNameNS.
> > > 
> > > Answering another question: gain is due to reduced pressure on GC, so producing
> > > new JS wrappers would most probably kill the optimization.  And Mozilla bug you
> > > spotted says roughly the same.
> > > 
> > > So the conclusion is we are waiting for changed HTML5 spec?
> > > 
> > > If yes, any ETA?
> > > 
> > > And thanks a lot for very interesting investigation of the question.
> > 
> > I think we should suggest a change or erratum to the DOM Level 3 Core spec. It
> > seems like even if returning a new object was intended, it's not what
> > implementations do. I suggest mailing public-webapps at w3.org to start a
> > discussion. Or I can do it if you'd rather not deal with the standards groups.
> 
> I see, thanks, Maciej.  I've sent an email cc'ing you.  If anyone else wants to
> be in the loop, just let me know.

I chatted with Ian this Monday.

He said that nobody is actively working on this part of the spec,
hence no answer.

He doesn't quite like idea of caching node lists for reasons like
properties assigned to result of one call would affect other calls,
and would rather see other browsers not doing the caching, but says
that it only could have a chance if clearly worded in the spec.  On
the other side "but if IE does it and it would make things faster...
maybe we should just do it"

So what would be resolution?  Do we want to see that in WebKit?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.