Unfortunately, not in any way that is universally practical.
The div:first query is obviously improvable, but when you get into
queries like "[EMAIL PROTECTED]" it becomes a lot less clear.
I'll think about improving TAG:first/last - as that seems like a
common case, at least.
--John
On 3/1/07, Yehuda Katz <[EMAIL PROTECTED]> wrote:
> This is a smart optimization for :first. John, is this doable?
>
> -- Yehuda
>
>
> On 3/1/07, Brice Burgess <[EMAIL PROTECTED] > wrote:
> > I am searching for the fastest way to fetch the first visible input of a
> > page, and currently using:
> > $(':input:visible')[0]
> >
> > I thought this could be improved with the :first selector, and indeed it
> > seems so (as it avoids memory assignments for all matched visible
> > inputs), so I narrowed it down to:
> > $(':input:visible:first')[0]
> >
> > I wanted to investigate the behavior further, so ran a few small tests
> > against http://docs.jquery.com/DOM/Traversing/Selectors
> >
> > The page was reset/refreshed for each test, and the profiling is being
> > done in firebug.
> >
> > My average results are as follows:
> >
> > $('*:first')[0]; == 25.014ms, 1168 calls
> > $('*')[0]; == 160.382ms, 1159 calls
> >
> > $('div:first')[0]; == 2.979ms, 122 calls
> >
> > This leads me to believe that despite the :first limit, all elements are
> > found, and then the first one returned. Does any jQuery selector exist
> > that *stops* matching after the first match is found? This would avoid
> > the n*x extra system calls?
> >
> > ~ Brice
> >
> > _______________________________________________
> > jQuery mailing list
> > discuss@jquery.com
> > http://jquery.com/discuss/
> >
>
>
>
> --
> Yehuda Katz
> Web Developer | Wycats Designs
> (ph) 718.877.1325
> _______________________________________________
> jQuery mailing list
> discuss@jquery.com
> http://jquery.com/discuss/
>
>
_______________________________________________
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
