John wrote: "You should always use $("#foo").find("p") in favor of $
("p", $("#foo")) "
I'm trying to extrapolate some general concepts from this 'rule'...
First, I *assume* these two statements are identical in performance:
$("p", $("#foo")) == $("p", "#foo")
If so, then does it matter what the scope selector is? What if the
scope is *not an ID*, and therefore not as fast to find, like::
$("div.myClass").find("p") in favor of $("p", "div.myClass") ???
If this is still true, then my understanding is that $("a").find("b")
syntax is ALWAYS faster than $("a, b")???
IF it is true that find() is always faster - or at least equal - to
specifying a scope selector/element, then it would seem that jQuery
should simply use the find() flow internally when a scope selector is
specfied. In other words, when a scope selector/element is specified,
find this element first and then 'call' the same method used for find
() - ie:
*** internally ***
$("p", $("#foo")) ==> $("#foo").find("p")
I can't think of any excepts to this - the result should always be
identical? If so, and performance is equal or superior, then *why not*
do this internally so the two statements above essentially become 100%
identical? It would just be two ways of expressing the same thing,
which is how it appears to users.
Am I off-base here? If so, which assumuption above breaks down?
Even if there is a good reason to treat the syntax differently
internally, I'm still interested to know if I should avoid using scope
selectors in favor of find() ***under all conditions*** - or only
under specific conditions?
/Kevin
On Feb 24, 5:58 pm, John Resig <jere...@gmail.com> wrote:
> I want to point out a couple things:
> 1) You should always use $("#foo").find("p") in favor of $("p", $
> ("#foo")) - the second one ends up executing $(...) 3 times total -
> only to arrive at the same result as doing $("#foo").find("p").
> 2) I generally dislike saying that there's one good way to do a
> selector (especially with one that has such bad syntax, as above) -
> especially since it may not always be that way.
>
> In fact, I've already filed a bug and I'll be looking in to this
> issue, possibly resolving it tonight or tomorrow - at which point the
> advice will be false again.http://dev.jquery.com/ticket/4236
>
> My recommendation is to always write the simplest, easiest to
> understand, expression: jQuery will try to do the rest to optimize it.
>
> --John
>
> On Feb 24, 10:23 am, Stephan Veigl <stephan.ve...@gmail.com> wrote:
>
>
>
> > Hi Karl,
>
> > $('#foo').find('p') and $('p', $('#foo')) are approximately of the same
> > speed.
>
> > I've put the test code on JSBin, so everybody can play around with it
> > and try other combinations :-)http://jsbin.com/ifemo
>
> > by(e)
> > Stephan
>
> > 2009/2/24 Karl Swedberg <k...@englishrules.com>:
>
> > > Hi Stephan,
> > > Thanks for doing this testing! Would you mind profiling
> > > $('#foo').find('p')
> > > as well? I suspect it will be roughly equivalent to $('p', $('#foo'))
> > > Cheers,
>
> > > --Karl
> > > ____________
> > > Karl Swedberg
> > >www.englishrules.com
> > >www.learningjquery.com
>
> > > On Feb 24, 2009, at 8:28 AM, Stephan Veigl wrote:
>
> > > Hi,
>
> > > I've done some profiling on this, and $("p", $("#foo")) is faster than
> > > $("#foo p") in both jQuery 1.2.6 and 1.3.2.
>
> > > the test HTML consists of 100 <p>s in a "foo" <div> and 900 <p>s in a
> > > "bar" <div>.
>
> > > However the factor differs dramatically:
> > > In 1.2.6 the speedup from $("p", $("#foo")) to $("#foo p") was between
> > > 1.5x (FF) and 2x (IE),
> > > while for 1.3.2 the speedup is 20x (FF) and 15x (IE).
>
> > > $("p", $("#foo")) is faster in 1.3.2, by a factor of 1.5 (both FF and IE),
> > > while $("#foo p") is _slower_ in 1.3.2 by 8.5x (FF) and 4.6x (IE).
>
> > > Even with an empty "bar" div $("p", $("#foo")) is faster by a factor up to
> > > 3x.
>
> > > Conclusion:
> > > If you have an ID selector, first get the element by it's ID and use
> > > it as scope for further selects.
>
> > > by(e)
> > > Stephan
> > > 2009/2/23 ricardobeat <ricardob...@gmail.com>:
>
> > > up to jQuery 1.2.6 that's how the selector engine worked (from the top
>
> > > down/left to right). The approach used in Sizzle (bottom up/right to
>
> > > left) has both benefits and downsides - it can be much faster on large
>
> > > DOMs and some situations, but slower on short queries. I'm sure
>
> > > someone can explain that in better detail.
>
> > > Anyway, in modern browsers most of the work is being delegated to the
>
> > > native querySelectorAll function, as so selector performance will
>
> > > become more of a browser makers' concern.
>
> > > - ricardo
>
> > > On Feb 23, 1:08 pm, Peter Bengtsson <pete...@gmail.com> wrote:
>
> > > I watched the John Resig presentation too and learned that CSS
>
> > > selectors always work from right to left.
>
> > > That would mean that doing this::
>
> > > $('#foo p')
>
> > > Would extract all <p> tags and from that list subselect those who
>
> > > belong to #foo. Suppose you have 1000 <p> tags of them only 100 are
>
> > > inside #foo you'll have wasted 900 loops.
>
> > > Surely $('#foo') is the fastest lookup possible. Doing it this way
>
> > > will effectively limit the scope of the $('p') search and you will
>
> > > never be bothered about any <p> tags outside #foo.
>
> > > Or am I talking rubbish?- Hide quoted text -
>
> - Show quoted text -
