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