- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 03 Jul 2013 10:50:28 -0400
- To: whatwg@lists.whatwg.org
On 7/3/13 3:58 AM, Mikko Rantalainen wrote: > Boris Zbarsky, 2013-06-29 05:02 (Europe/Helsinki): >> On 6/28/13 6:51 PM, Tab Atkins Jr. wrote: >>> querySelector is simply a more powerful querying function than the old >>> DOM methods, >> >> And somewhat slower as a result, note. > > If that's true, I would consider that as a bug. It should be really > simple for an UA implementation to optimize as following > > querySelector("#foo") -> getElementById("foo") They're not equivalent in general; see my comments earlier in this thread. You have to actually parse the argument to querySelector with something like a selector parser to see whether you can make this optimization. Note that UAs already do this at that point, but there is still more work than getElementById. > querySelectorAll("foo") -> getElementsByTagName("foo") Those are also not equivalent. Much more so than the other, to the point where optimizing this sanely is much harder. The thing on the right selects on the qualified name while the thing on the left selects on the localName. And they return different kinds of objects, too. So something like this: getElementsByTagName("foo")[1] can be way faster than querySelectorAll("foo")[1], because the latter has to walk the entire DOM while the former only has to walk to the second <foo>. > Or, were you really talking about the difference between having to scan > the string given as a parameter to see if it looked like "simple" > selector that matches the old DOM method implementation? For the #foo case, this is exactly right. > I'd *guess* that that difference is meaningless compared to > walking the element tree or even doing hash lookup for the id You'd guess wrong, and I've got profiles to prove it. ;) -Boris
Received on Wednesday, 3 July 2013 14:50:59 UTC