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
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
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
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
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
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
> 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
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
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
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
> 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?
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
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.
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
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
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,
> 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
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
y single time for << querySelector >>
which cannot return a cached result.
From: curvedm...@gmail.com
Date: Mon, 27 Apr 2015 16:57:23 +0800
To: public-webapps@w3.org
Subject: Why is querySelector much slower?
Intuitively, querySelector('.class') only needs to
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. Why that's not the case?
See http://jsperf.com/queryselect
20 matches
Mail list logo