W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Why is querySelector much slower?

From: Elliott Sprehn <esprehn@chromium.org>
Date: Mon, 27 Apr 2015 21:27:50 -0700
Message-ID: <CAO9Q3i+=K5hw8aAEHcVDOX_Gg-t_UHa1r+rT1hBAw7jxbM3CzA@mail.gmail.com>
To: Glen Huang <curvedmark@gmail.com>
Cc: public-webapps <public-webapps@w3.org>, Ryosuke Niwa <rniwa@apple.com>, Jonas Sicking <jonas@sicking.cc>
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
> >
>
>
>
Received on Tuesday, 28 April 2015 04:28:19 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC