Re: Why is querySelector much slower?

On 4/29/15 12:23 AM, Glen Huang wrote: because of the proxy machinery involved on the JS engine side Do you mean the cost introduced by passing a C++ object into ecmascript world? No, it's the cost introduced by needing custom property behavior for integer-named properties on lists (and in p

Re: Why is querySelector much slower?

Ww, this is pure gold. Thank you so much for such thorough explanation, any even took the trouble to actually implement optimizations to make sure the numbers are right. I'm so grateful for the work you put into this just to answer my question. How do I accept your answer here? ;) > So what

Re: Why is querySelector much slower?

On 4/28/15 2:59 AM, Glen Huang wrote: Looking at the microbenchmark again, for Gecko, getElementById is around 300x faster than querySelector('#id'), and even getElementsByClassName is faster than it. This is why one should not write microbenchmarks. ;) Or at least if one does, examine the

Re: Why is querySelector much slower?

On 4/28/15 2:44 AM, Glen Huang wrote: But If I do getElementsByClass()[0], and LiveNodeList is immediately garbage collectable Then it will only be collected the next time GC happens. Which might not be for a while. -Boris

Re: Why is querySelector much slower?

On 4/28/15 1:58 AM, Glen Huang wrote: Just a quick follow up question to quench my curiosity: if I do "list[1]" and no one has ever asked the list for any element, Gecko will find the first two matching elements, and store them in the list, if I then immediately do "list[0]", the first element

Re: Why is querySelector much slower?

On 4/28/15 2:13 AM, Glen Huang wrote: On second thought, if the list returned by getElementsByClass() is lazy populated as Boris says, it shouldn't be a problem. The list is only updated when you access that list again. Mutations have to check whether the list is marked dirty already or not. T

Re: Why is querySelector much slower?

> querySelector with an id selector does in fact benefit from the id hashtable Looking at the microbenchmark again, for Gecko, getElementById is around 300x faster than querySelector('#id'), and even getElementsByClassName is faster than it. It doesn't look like it benefits much from an eagerly

Re: Why is querySelector much slower?

But If I do getElementsByClass()[0], and LiveNodeList is immediately garbage collectable, then if I change the DOM, Blink won't traverse ancestors, thus no penalty for DOM mutation? > On Apr 28, 2015, at 2:28 PM, Elliott Sprehn wrote: > > > > On Mon, Apr 27, 2015 at 11:13 PM, Glen Huang

Re: Why is querySelector much slower?

On Mon, Apr 27, 2015 at 11:13 PM, Glen Huang wrote: > On second thought, if the list returned by getElementsByClass() is lazy > populated as Boris says, it shouldn't be a problem. The list is only > updated when you access that list again. > The invalidation is what makes your code slower. Speci

Re: Why is querySelector much slower?

On second thought, if the list returned by getElementsByClass() is lazy populated as Boris says, it shouldn't be a problem. The list is only updated when you access that list again. > On Apr 28, 2015, at 2:08 PM, Glen Huang wrote: > >> Live node lists make all dom mutation slower >> > Haven't

Re: Why is querySelector much slower?

> Live node lists make all dom mutation slower > Haven't thought about this before. Thank you for pointing it out. So if I use, for example, lots of getElementsByClass() in the code, I'm actually slowing down all DOM mutating APIs?

Re: Why is querySelector much slower?

Wow, it's now super clear. Thanks for the detailed explanation. Just a quick follow up question to quench my curiosity: if I do "list[1]" and no one has ever asked the list for any element, Gecko will find the first two matching elements, and store them in the list, if I then immediately do "li

Re: Why is querySelector much slower?

On 4/27/15 11:27 PM, Glen Huang wrote: When you say "var node = list[0];" walks the DOM until the first item is found, do you mean it only happens under the condition that some previous code has changed the DOM structure? Or that no one has ever asked the list for its [0] element before, yes.

Re: Why is querySelector much slower?

Live node lists make all dom mutation slower, so while it might look faster in your benchmark it's actually slower elsewhere (ex. appendChild). Do you have a real application where you see querySelector as the bottleneck? On Apr 27, 2015 5:32 PM, "Glen Huang" wrote: > I wonder why querySelector

Re: Why is querySelector much slower?

I wonder why querySelector can't get the same optimization: If the passed selector is a simple selector like ".class", do exactly as getElementsByClassName('class')[0] does? > On Apr 28, 2015, at 10:51 AM, Ryosuke Niwa wrote: > > >> On Apr 27, 2015, at 7:04 PM, Jonas Sicking wrote: >> >> On

Re: Why is querySelector much slower?

Thank you for the sample code. It's very helpful. When you say "var node = list[0];" walks the DOM until the first item is found, do you mean it only happens under the condition that some previous code has changed the DOM structure? If not, the returned list object will be marked as up-to-day,

Re: Why is querySelector much slower?

> On Apr 27, 2015, at 7:04 PM, Jonas Sicking wrote: > > On Mon, Apr 27, 2015 at 1:57 AM, Glen Huang wrote: >> Intuitively, querySelector('.class') only needs to find the first matching >> node, whereas getElementsByClassName('.class')[0] needs to find all matching >> nodes and then return the f

Re: Why is querySelector much slower?

On Mon, Apr 27, 2015 at 1:57 AM, Glen Huang wrote: > Intuitively, querySelector('.class') only needs to find the first matching > node, whereas getElementsByClassName('.class')[0] needs to find all matching > nodes and then return the first. The former should be a lot quicker than the > latter. Wh

RE: Why is querySelector much slower?

Not sure this is a public-webapps issue but I'm pretty sure however that the reason is the return values of << getElement*By*(...) >> are cached by the browser which means that you end up not doing the work at all at some point in the loop, while you probably do it every single time for << query