JavaScript Performance: jQuery.each and .each versus alternatives

Iterating across an array is a significant feature of JavaScript development. There are multiple methods available to achieve this, the native for and while loops and if you are using the jQuery JavaScript library there is jQuery.each and .each.

jQuery.each is designed to iterate over arrays and array like objects. .each is designed to iterate over jQuery objects and execute a function for each.

It seems to be a commonly held belief that a for or while loop should be used instead of the two jQuery alternatives. This belief is based on performance, as jQuery has to invoke additional code to complete the same task.

I tried a number of sources but the best way to find the truth is through experimentation. To create an experiment i use jsper.com as it allows you to run performance tests on snippets of your code, it is particularly useful as the same test can be run from many different browsers.

Having a quick look at jsper.com i found some existing tests, one of interest was Addy Osmani’s revision which had comparative results for for, while and jQuery.each loops. The .each test though seemed to be off by an order of magnitude. What’s missing here is that .each will look for the array of objects in the DOM, performing the same task as var a = $(‘*’).get() which is declared outside of the iteration for all the other test.

This represents an unfair advantage for the other methods, so i created a new revision of the test where the DOM operation was done as part of the test. From this .each is still slower than native methods but only by a small margin.

Using these results it would seem that the advantage of performance is insufficient to force usage of the for or while loop over the jQuery equivalents. Although there may be a saving in performance the jQuery abstraction allows for shorter, more succinct code, using a standard format that is easier to understand.

Common abstractions are useful in software development, if using jQuery i would recommend using jQuery.each and .each rather than a native approach; which should be kept in reserve for applications that require maximum performance.

4 Responses to JavaScript Performance: jQuery.each and .each versus alternatives

  1. rayui says:

    Obviously, this is all assuming that you need to access the DOM :P It would be interesting to see how this compare’s with the underscore.js method.

  2. George Paterson says:

    If you weren’t accessing the DOM it would be a comparison of for and while against jQuery.each; which should still be competitive. The DOM at that point is merely providing an array to iterate across.

    If underscore.js has a publically accessible URL to link to in jsperf you could do the test. It would be interesting to see.

    In fact i would like to see a localised version which we could use for continuous integration along with functional tests. If we develop using truly modular code and if the site we’re developing has a performance issue, using the test you should be able to identify the problem code quite quickly.

  3. Mitchell says:

    There are two kinds of “each”. You tested jQuery.each, which is a utility function for iterating over any object or array. The performance problems are real, but they come from each, which iterates over DOM nodes. It’s the DOM access that makes it slow.

  4. George Paterson says:

    Hi Mitchell, that right DOM access is the issue but the tests had previously discounted DOM access for all the test except .each where DOM access is integral.

    These other tests weren’t a like for like comparison, if… else $.each and the other methods needed DOM access as part of the test if the comparison was to be fair.

Comment on JavaScript Performance: jQuery.each and .each versus alternatives

Your email address will not be published.

You may use these HTMLtags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>