Question

I find the practice of caching an array’s length property inside a for loop quite distasteful. As in,

for (var i = 0, l = myArray.length; i < l; ++i) {
    // ...
}

In my eyes at least, this hurts readability a lot compared with the straightforward

for (var i = 0; i < myArray.length; ++i) {
    // ...
}

(not to mention that it leaks another variable into the surrounding function due to the nature of lexical scope and hoisting.)

I’d like to be able to tell anyone who does this “don’t bother; modern JS JITers optimize that trick away.” Obviously it’s not a trivial optimization, since you could e.g. modify the array while it is being iterated over, but I would think given all the crazy stuff I’ve heard about JITers and their runtime analysis tricks, they’d have gotten to this by now.

Anyone have evidence one way or another?

_{And yes, I too wish it would suffice to say “that’s a micro-optimization; don’t do that until you profile.” But not everyone listens to that kind of reason, especially when it becomes a habit to cache the length and they just end up doing so automatically, almost as a style choice.}

Answer 1

It depends on a few things:

• Whether you’ve proven your code is spending significant time looping
• Whether the slowest browser you’re fully supporting benefits from array length caching
• Whether you or the people who work on your code find the array length caching hard to read

It seems from the benchmarks I’ve seen (for example, here and here) that performance in IE < 9 (which will generally be the slowest browsers you have to deal with) benefits from caching the array length, so it may be worth doing. For what it’s worth, I have a long-standing habit of caching the array length and as a result find it easy to read. There are also other loop optimizations that can have an effect, such as counting down rather than up.

Here’s a relevant discussion about this from the JSMentors mailing list: http://groups.google.com/group/jsmentors/browse_thread/thread/526c1ddeccfe90f0