Your test case is not comparing a raw implementation

You are still using jQuery $ inside the loop, it should be pure
document.getElementById("test");

When you remove the $ from your test case and use native
implementation you will be getting numbers in the following range:

FF
ID Raw: 1 ID jQuery: 17
Class Raw: 1 Class jQuery: 495

Safari
ID Raw: 1 ID jQuery: 5
Class Raw: 1 Class jQuery: 228


        var idNormal = (new Date).getTime() - idStart;
        idStart = (new Date).getTime();
        for ( var i = 0; i < 500; i++ ) {
                document.getElementById("test");
        }
        var idRaw = (new Date).getTime() - idStart;

        var cNormal = (new Date).getTime() - cStart;
        cStart = (new Date).getTime();
        for ( var i = 0; i < 100; i++ ) {
                document.getElementsByClassName("test");
        }


On Feb 16, 8:43 am, John Resig <jere...@gmail.com> wrote:
> Umm - that's not true at all.
>
> I created a test for you to 
> see:http://dev.jquery.com/~john/ticket/class-speed/
>
> In Firefox 3 I'm getting:
> ID Raw: 9 ID jQuery: 22 (over 500 queries)
> Class Raw: 1108 Class jQuery: 778 (over 100 queries)
>
> In Safari 3.2 I'm getting:
> ID Raw: 1 ID jQuery: 3 (over 500 queries)
> Class Raw: 224 Class jQuery: 184 (over 100 queries)
>
> So not only is jQuery's class implementation faster but the ID
> searching has an approximately 0.026 milliseconds overhead - that's
> 2.6% of 1 millisecond per query - an absolutely acceptable figure to
> be able to live with.
>
> --John
>
> On Mon, Feb 16, 2009 at 8:28 AM, RobG <rg...@iinet.net.au> wrote:
>
> > On Feb 16, 5:30 pm, SteelRing <steelr...@gmail.com> wrote:
> >> This may sound stupid to y'all jquery practitioners, but i wonder
> >> which method is fastest (recommended) for selecting a cell with a
> >> class in a big table (think like 1000+ rows 100+ columns):
>
> > Fastest: the browser-native getElementsByClassName  (recent Firefox,
> > Opera, Safari) is 20 to 40 times faster than $('.className'), as a
> > bonus you get a live collection.
>
> > Alternatively, XPath is probably just as quick but the result isn't
> > live (supported by the same set of browsers).
>
> > The jQuery way is to use a CSS selector, however it is much slower
> > than other methods (except perhaps in IE).
>
> >> ("#tableid tbody tr.rowclass td.cellclass") or is it ("td.cellclass")
> >> or (".cellclass").
>
> >> And how about if the cell happens to have a unique id:
>
> >> ("#tableid tbody tr#uniquerow td#uniqueid") or just ("#uniqueid")
>
> > If speed really matters, getElementById is more than 7 times faster
> > than $('#...') in Firefox and  4 times faster in Safari.
>
> >> Philosophically, the question being is it better to put as much detail
> >> as structurally already known by the programmer into the selector or
> >> just anything goes and let jquery handle it as long as it works.
>
> > There is no selector optimisation that I can see in jQuery other than
> > using getElementById after discovering '#...' (and the overhead of
> > discovering that means it is 4 to 6 times slower than gEBI).
>
> > As a general rule, keep the selector to a minimum that concisely
> > describes the element - cells must be inside table, table section and
> > row elements, including those in a selector doesn't seem to help.  An
> > ID for the starting selector likely does.
>
> > Do some testing for particular circumstances, the most efficient
> > method will emerge.  Don't forget to include browser-native methods
> > where available.
>
> > --
> > Rob

Reply via email to