Again, the details are after the jump.

For reference, here’s the original implementation of jQuery.each from jQuery 1.3.2 (it hasn’t changed much for 1.4):

function( object, callback, args ) {
 var name, i = 0, length = object.length;

 if ( args ) {
  ... omitted ...

 } else {
  if ( length === undefined ) {
    ... omitted ...
  } else
   for ( var value = object[0];
    i < length && callback.call( value, i, value ) !== false; value = object[++i] ){}
 }

 return object;
}

I cut out some pieces relating to iterating over Objects instead of Arrays, and some internal-only code, just for brevity. You can see that at its core, each just iterates over the array with a regular for loop and calls the provided callback for each element. It’s using the call function to invoke the callback so it can set this to the value of each element in the array in turn, and passes the index in the array and the value at that index as parameters to the callback as well.

I ended up trying four different modifications of jQuery’s each function. I also allowed myself to actually change the signature of each, which would likely break much existing code written on top of jQuery, but it gave me a lot more freedom to tweak things.

The first was to try using native Array.forEach (where available). I had to pass in my own callback to forEach that reversed the order of the index and value arguments to the function, since jQuery.each and Array.forEach put those arguments in opposite order. Of course, I had to fall back on the original for loop implementation for IE. This modification retains the complete behavior from the original implementation.

if (jQuery.isFunction(object.forEach) ) {
  object.forEach(function(value, i) {
    callback.call(value, i, value);
  });
}
else {
  for (var value = object[0];
    i < length && callback.call(value, i, value) !== false;
    value = object[++i]) {}
}

Next, I tried skipping the callback that switches the order of arguments and just passing the user's callback directly to forEach. I had to modify the fallback to match this. Notice in both cases we no longer set this to the current element in the iteration - Array.forEach doesn't support that directly. We're solidly in non-backwards-compatible change territory here.

if (jQuery.isFunction(object.forEach) ) {
  object.forEach(callback);
}
else {
  for (var value = object[0];
    i < length && callback.call(null, value, i) !== false;
    value = object[++i]) {}
}

I noticed in testing this out that Firefox seems to really struggle with using call with a frequently-changing value for this (the first parameter) so I tried another variation that didn't use native Array.forEach but just didn't change this in the call (I let it be the whole array each time):

for (var value = object[0];
  i < length && callback.call(object, i, value) !== false;
  value = object[++i]) {}

After that, I wondered why use call at all (I might be missing something important here about how JavaScript function invocation works - please correct me!) So I tried a version that just called the callback directly.

for (var value = object[0];
  i < length &&  callback(i, value) !== false;
  value = object[++i]) {}

With these four variations, I went and tested how long it took for them to iterate over a 500,000 element array in different browsers. In the previous tests I used 100,000 elements but the tests completed too fast to get meaningful results (which should tell you how fast this stuff is to begin with!). As in the previous post, the absolute numbers don't really mean much - it's the comparison between the different approaches that matters.

We find that Firefox 3.6 improves over Firefox 3.5, IE is slow no matter what (though faster than Firefox 3.5 for vanilla jQuery.each), and the Webkit browsers are both very fast. What's more interesting is to look at each time as a percentage of the stock jQuery implementation:

A couple of things jump out at us - Array.forEach doesn't buy us anything if we have to provide a callback to reverse the inputs. If we can use the native forEach signature, it gets much faster, but not by an order of magnitude. Not varying this helps a lot in Firefox and Chrome - I suspect some runtime optimizations kick in if this stays the same, but not if it's changing. The overhead of call is significant - it tends to matter more than anything else here. The last thing to note is that, weirdly, Safari 4 is fastest with the stock jQuery.each - I wonder if they've optimized specifically for that pattern.

Armed with this knowledge, I customized a copy of jQuery 1.4 to stop referring to this in its uses of each, switched the for loop to call the callback directly instead of using call, and reverse-engineered the performance tests John Resig used for the jQuery 1.4 release notes. Using these tests, I compared my custom version to the released jQuery 1.4.

The result: optimizing array iteration speed made no difference. The real work being done by jQuery (DOM manipulation, etc) totally overshadows any array iteration overhead. Reducing that overhead even by 80% doesn't matter at all. We learned a few things about how fast Array.forEach is and how setting this in call affects performance, but we haven't found some magic way to make our code, or jQuery overall, any faster. Furthermore, the only improvement that would have preserved the signature of the original jQuery API was actually slower than the existing implementation! It's not worth losing this in each for any of these speed gains.

There was one small improvement to jQuery, however - a very small boost to the compressability of the library. Using explicit arguments to each instead of this to refer to the current element being iterated means that YUI Compressor or Google Closure Compiler can use one character for that item, instead of 4 for this (since this is a keyword). In practice, that saved about 197 bytes out of 69,838 - still not a huge win. But I like to avoid using this in my each anyway, just so I get to use semantically meaningful variable names, so it's nice to see that I'm saving a byte or two along the way.

PS: Aside from the "jQueryness" of it, I wondered why each set this to the current element in the array anyway. I have one idea - if this is set to the current element in the array for each invocation of the callback, you can do cleaner OO-style JavaScript. For example, let's say you have a Dialog object that has a close method. Of course the close method would just use this to refer to the object it's a member of. But if you had an array of Dialogs and wanted to say "$.each(dialogs, Dialog.prototype.close)" and each didn't set this to each Dialog in turn, everything would get confused. Of course, in jQuery 1.4 you can get around this using jQuery.proxy, which goes ahead and uses apply (a variant of call) anyway.

I’d also recently seen an article on Ajaxian about a new library, Underscore.js that claimed to include, among other nice Ruby-style functional building blocks, an each function that was powered by the JavaScript 1.5 Array.forEach when it was available (and degrading for IE). I wondered how much faster that was than jQuery’s $.each, and that got me to thinking about all the different ways to iterate over an array in JavaScript, so I decided to test them out and compare them in different browsers.

This gets pretty long so the rest is after the jump.

I went with six different approaches for my test. Each function would take a list of 100,000 integers and add them together. You can try the test yourself. The first was a normal for loop, with the loop invariant hoisted:

var total = 0;
var length = myArray.length;
for (var i = 0; i < length; i++) {
  total += myArray[i];
}
return total;

And then again without the invariant hoisted, just to see if it makes a difference:

var total = 0;
for (var i = 0; i < myArray.length; i++) {
  total += myArray[i];
}
return total;

Next I tried a for in loop, which is really not a good idea for iterating over an array at all - it's really for iterating over the properties of an object - but is included because it's interesting and some people try to use it for iteration:

var total = 0;
for (i in myArray) {
  total += myArray[i];
}
return total;

Next I tried out the Array.forEach included in JavaScript 1.5, on its own. Note that IE doesn't support this (surprised?):

var total = 0;
myArray.forEach(function(n, i){
  total += n;
});
return total;

After that I tested Underscore.js 0.5.1's _.each:

var total = 0;
_.each(myArray, function(i, n) {
  total += n;
});
return total;

And then jQuery 1.3.2's $.each, which differs from Underscore's in that it doesn't use the native forEach where available, and this is set to each element of the array as it is iterated:

var total = 0;
$.each(myArray, function(i, n){
  total += n;
});
return total;

I tested a bunch of browsers I had lying around - Firefox 3.5, Chrome 3, Safari 4, IE 8, Opera 10.10, and Firefox 3.7a1pre (the bleeding edge build, because I wanted to know if Firefox is getting faster). I tried testing on IE6 and IE7 in VMs but they freaked out and crashed. The tests iterated over a list of 100,000 integers, and I ran each three times and averaged the results. Note that this is not a particularly rigorous test - other stuff was running on my computer, some of the browsers were run in VMs, etc. I mostly wanted to be able to compare different approaches within a single browser, not compare browsers, though some differences were readily apparent after running the tests.

I've highlighted some particularly interesting good and bad results from the table (in green and red, respectively). Let's see what we can figure out from these tests. I'll get the obvious comparisons between browsers out of the way - IE is really slow, and Chrome is really fast. Other than that, they each seem to have some mix of strengths and weaknesses.

First, the for loop is really fast. It's hard to beat, and it's clear that if you've got to loop over a ton of elements and speed is important to you you should be using a for loop. It's sad that it's so much slower in IE and Opera, but it's still faster than the alternative. Opera's result is somewhat surprising - while it's not particularly fast anywhere, it's not nearly as slow as IE on the other looping methods, but it's still pretty slow on normal for loops. Notice that IE8 is the only browser where manually hoisting the loop invariant in the for loop matters - by almost 3x. I'm guessing every other browser automatically caches the myArray.length result, leading to roughly the same performance either way, but IE doesn't.

Next, it turns out that for in loops are not just incorrect, they're slow - even in otherwise blazingly-fast Chrome. In every browser there's a better choice, and it doesn't even get you much in terms of convenience (since it iterates over indices of the array, not values). Safari is particularly bad with them - they're 10x slower than its next slowest benchmark. Just don't use for in!

The results for the native Array.forEach surprised me. I expected some overhead because of the closure and function invocation on the passed-in iterator function, but I didn't expect it to be so much slower. Chrome and Safari seem to be pretty well-optimized, though it is still several times slower than the normal for loop, but Firefox and Opera really chug along - especially Firefox. Firefox 3.7a1pre seems to have optimized forEach a bit (probably more than is being shown, since 3.7a1pre was running in a VM while 3.5 was running on my normal OS).

Underscore.js each's performance is pretty understandable, since it boils down to native forEach in most browsers, it performs pretty much the same. However, in IE it has to fall back to a normal for loop and invoke the iterator function itself for each element, and it slows way down. What's most surprising about that is that having Underscore invoke a function for each element within a for loop is still 10x slower in IE than just using a for loop! There must be a lot of overhead in invoking a function with call in IE - or maybe just in invoking functions in general.

Lastly we have jQuery's each, which (excluding for in loops) is the slowest method of iterating over an array in most of the browsers tested. The exception is Safari, which consistently does better with jQuery's each than it does with Underscore's or the native forEach. I'm really not sure why, though the difference is not huge. IE's performance here is pretty much expected, since Underscore degrades to almost the same code as jQuery's when a native forEach isn't available. Firefox 3.5 is the real shocker - it's drastically slower with jQuery's each. It's even slower than IE8, and by a wide margin! Firefox 3.7a1pre makes things better, but it's still pretty embarassing. I have some theories on why it's so slow in Firefox and what could be done about it, but those will have to wait for another post.

It'd be interesting to try out some of the other major JavaScript libraries' iteration functions and compare them with jQuery and Underscore's speeds - I'm admittedly a jQuery snob, but it'd be interesting to see if other libraries are faster or not.

It's worth noting that, as usual, this sort of performance information only matters if you're actually seeing performance problems - don't rewrite your app to use for loops or pull in Underscore.js if you're only looping over tens, or hundreds, or even thousands of items. The convenience of jQuery's functional-style each means it's going to stay my go-to for most applications. But if you're seeing performance problem iterating over large arrays, hopefully this will help you speed things up.