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" <curvedmark@gmail.com> wrote:

> 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 <rniwa@apple.com> wrote:
> >
> >
> >> On Apr 27, 2015, at 7:04 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >> On Mon, Apr 27, 2015 at 1:57 AM, Glen Huang <curvedmark@gmail.com>
> 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. Why that's not the case?
> >>
> >> I can't speak for other browsers, but Gecko-based browsers only search
> >> the DOM until the first hit for getElementsByClassName('class')[0].
> >> I'm not sure why you say that it must scan for all hits.
> >
> > WebKit (and, AFAIK, Blink) has the same optimization. It's a very
> important optimization.
> >
> > - R. Niwa
> >
>
>
>