4

I saw this snippet in Ember.js:

  for (var i=0, l=deps.length; i<l; i++) {
    if (deps[i] === 'exports') {
      reified.push(exports = {});
    } else {
      reified.push(requireModule(resolve(deps[i])));
    }
  }

Please take a look at var i=0, l=deps.length; i<l; i++, the length of deps is defined before the loop. I was wonder why did they have to do that instead of just use var i=0; i<deps.length; i++. I think maybe this is a "performance trick", so I decided to make a test on jsperf:

http://jsperf.com/predefined-length-vs-inline-defined-length

The result shows that the second one is faster. So there is must be another reason they used the first one.

Anyone have any idea? Thanks a lot.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
Tony Dinh
  • 6,668
  • 5
  • 39
  • 58
  • Do you realize the difference is nothing. One sets a variable, one does not. Older browsers you needed to store the length so it ran faster. Modern browsers, it makes no difference. – epascarello Jun 22 '14 at 15:16
  • 2
    It's because the statements in the for loop is looked up on every iteration, so you save a little on caching the length instead of looking it up on every iteration, but most of the time the difference is not noticeable, so it doesn't really matter. And as mentioned, newer browsers already optimize this internally. – adeneo Jun 22 '14 at 15:16
  • 2
    It should be noted that if order doesn't matter, it's generally just easier and faster to iterate in reverse `for (var i=deps.length; i--;) ...` – adeneo Jun 22 '14 at 15:18

2 Answers2

4

This is not so much a good practice as a small performance optimization. In very large arrays it will yield a significant performance improvement. The reason for doing this is that it "caches" the length value of the array, NodeList, etc., so that in your loop's exit condition you don't have to re-access the property every time because it is stored inside the variable.

As with any code, the performance gain varies and it could be faster or slower depending on the browser.

Alex W
  • 37,233
  • 13
  • 109
  • 109
0

thats a tricky one as we all think that calculating the length will be a better one. But actually calculating the length will happen only once in either case. But in the first one you are declaring one more variable besides the iterator 'i'. So the VM needs to allocate a temporary space for it till the loop ends; Thats the reason first is the slowest.

Hope this helps you.

Bharath
  • 519
  • 4
  • 7
  • The _condition_ part of the loop needs to be evaluated before **every** execution of the loop body. So `i < l` always only does the comparison between two variables, while `i < deps.length` always would theoretically require to access the property `length` of `deps` (and that is slower). The JS engine may be intelligent enough to realize that it is able simplify `i < deps.length` to `i < l`, thats more likely the reason why there is no difference for both tests. `3.32` to `3.49` can't be seen as difference especially as it flips when you repeat it. – t.niese Jun 22 '14 at 15:59