W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments

From: James Greene <james.m.greene@gmail.com>
Date: Fri, 18 Oct 2013 14:16:48 -0500
Message-ID: <CALrbKZgKNWo+SRD3e=TZbxrynvzux4JCffZ5=NOry0_jtMmNCw@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:12 UTC