- From: James Greene <james.m.greene@gmail.com>
- Date: Fri, 18 Oct 2013 14:16:48 -0500
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Glenn Maynard <glenn@zewt.org>, Ryosuke Niwa <rniwa@apple.com>, whatwg <whatwg@lists.whatwg.org>, Tim Streater <tim@clothears.org.uk>, Boris Zbarsky <bzbarsky@mit.edu>, Ian Hickson <ian@hixie.ch>
>
> There's no perf boost available for searching by id on an arbitrary
> element. The reason you may get a better perf for the normal
> functions is that documents cache a map from id->element on
> themselves, so you just have to do a fast hash-lookup. Arbitrary
> elements don't have this map (it would be way too much memory cost),
> so it'll fall back to a standard tree search, exactly as a
> querySelector would.
Hmm, I suppose that makes sense. Bummer. Thanks for the concise
explanation!
Sincerely,
James Greene
On Fri, Oct 18, 2013 at 2:11 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:
> On Fri, Oct 18, 2013 at 11:09 AM, James Greene <james.m.greene@gmail.com>
> wrote:
> > I would also love to see `getElementById` added to the
> HTMLElement/Element
> > interface. It would be nice to capitalize on that potential perf boost in
> > jQuery as well.
>
> There's no perf boost available for searching by id on an arbitrary
> element. The reason you may get a better perf for the normal
> functions is that documents cache a map from id->element on
> themselves, so you just have to do a fast hash-lookup. Arbitrary
> elements don't have this map (it would be way too much memory cost),
> so it'll fall back to a standard tree search, exactly as a
> querySelector would.
>
> ~TJ
>
Received on Friday, 18 October 2013 19:17:32 UTC