JQuery.fn.each vs. jQuery.fn.quickEach | Hacker News Reader

JQuery.fn.each vs. jQuery.fn.quickEach

jsperf.com

33 pointsalbemuth11 comments

You don't always need a jQuery object in the loop, and providing one encourages people to do slow things. For example, if you want to see if a check box is checked, `this.checked` is 100 times faster [http://jsperf.com/bens-test] than `$(this).is(":checked")`. (Sorry about the lame name, I was hanging out with Ben Alman after the jQuery Conference, it was late, and I was tired).

If you do need a jQuery object, you can use James Padolsey's trick by keeping your own single-item jQuery object outside the `.each()` and update/reuse it inside.

While I agree, the thing that jQuery does, and this was outlined a long while ago in a presentation is that different browsers have different behaviors sometimes for some of the most simple things. Querying is one of those, and the list goes on. Sometimes there are just browser bugs! Frameworks like jq and others ensure a consistent behavior between different browsers.

Also note, native browser calls will always be faster. JQ gives you some major power though. It is always best to optimize the big parts of your performance with jq and other frameworks getting the logic correct, then these micro optimizations can be made, including this iterator and your this.checked. However for a general use case, this iterator is exactly what people need as it solves the 70% case.

Judging by one of the forks, it may not make much of a difference in real-world usage:

http://jsperf.com/jquery-each-vs-quickeach/9

The difference may not be as dramatic as the original example, but a 10-25% performance increase isn't too shabby.

True - reworded my post a bit to clarify.

Did not expect the page to start running the benchmark, let alone before the page finished loading.

I am impressed by the Chrome 13 results

    292,938 vs. 51,740

that is almost x6 faster, and almost as twice as my current chrome (11)

Causes FF 3.6.16 on Ubuntu 10.10 to crash.

As others have mentioned, the page loads a Java applet. That'd be my first guess at the cause of the crash.

Why is this page asking to load Java?

Looks like it's loading a high resolution timer called nano.jar. http://benchmarkjs.com/

Reply on news.ycombinator.com