http://jsperf.com/testing-foreach-vs-for-loop
It was my understanding that Test Case 2 should run more slowly than Test Case 1 -- I wanted to see how much more slowly. I
UPDATE:
A lot of the old tricks in these answers are great for interpreted JS in older browsers.
In any modern JS implementation including all modern browsers, Node, and the latest mobile webviews, inline functions can actually be cached by the JIT (JS compiler), making forEach a much faster option for array iteration, typically. It used to be the opposite where just making calls to a function repeatedly required a build-up/teardown process that could severely diminish performance of a non-trivial loop.
For best performance I'd avoid referencing anything that wasn't passed as an argument or defined inside the function itself if you don't have to. I'm not 100% sure that matters but I could see why it might.
Getter values that involve any kind of lookup process like array lengths or DOM node properties are probably also still best cached to a variable.
But beyond that I'd try to just let the basic principle of work avoidance guide your perf efforts. Pre-calculating things that don't need to be recalculated in a loop, or caching a query selector result to var rather than rummaging in the DOM repeatedly are good examples of this. Trying too hard to take advantage of JIT behavior is probably going to get pretty arcane and not likely to hold up over time or across all JITs.
OLD ANSWER:
Okay, forget wall of text. Bullet points:
var i = someArray.length; //length is cached
someArray.reverse(); //include this only if iterating in 0-(length-1) order is important
while(i--){
//run a test statement on someArray[i];
}
length is cached and immediately made into the index
The benefit of iterating backwards in JS AFAIK is avoiding a logical operator with two operands. In this case we're just evaluating a number. It's true or it's zero and false.
I also find it elegant.