2

Is it more efficient to declare a variable with another variable's length before doing a for-loop or should the length be calculated within the loop.

I'm certain the answer depends on how big the array is that the length is being calculated it on. I just always see

for ( var i = 1; i <= theVar.length; i++ ) {

}

but then i was told that it is less resource intensive to do 

var theVarLen = theVar.length

for ( var i = 1; i <= theVarLen; i++ ) {

}

as it avoids the recalculation of the length every iteration.

Or does it depend on specific circumstances so much it's impossible to make a categorical decree?

Or, does it not really matter at all..?

Thanks a bunch!

1252748
  • 14,597
  • 32
  • 109
  • 229
  • Test it: http://jsperf.com. But long story short, the length is not recomputed, it's a fixed value which gets updated whenever the array changes. You save one property lookup per iteration which really can make a difference, depending on the number of iterations (`->` length of the array). – Felix Kling Aug 06 '12 at 00:03
  • 1
    possible duplicate of [Is reading the `length` property of an array really that expensive an operation in JavaScript?](http://stackoverflow.com/questions/5752906/is-reading-the-length-property-of-an-array-really-that-expensive-an-operation) – Felix Kling Aug 06 '12 at 00:07
  • As a side note I see it done in this manner a lot too: `for(var i = 0, len = a.length; i < len; i++)` – Joseph Marikle Aug 06 '12 at 00:08
  • I've seen `while (theLen-->=0) …`. I think some folks think it looks cool because it has an ambiguous arrow-looking operator in it. Personally I don't like it. ;) – kojiro Aug 06 '12 at 00:10
  • @JosephMarikle hmm. what advantage do you think that has? it's doing both things! – 1252748 Aug 06 '12 at 01:02
  • _"I just always see"_ - As an aside, surely you're not really always seeing loops that start at index `1`... – nnnnnn Jun 27 '13 at 14:33

2 Answers2

4

Well, let's find out. I've created a test here that you can run: http://jsperf.com/loop-length-caching

Browsers seem to store the length of the array once it is created (and possibly modified), so there are no huge speed benefits from storing the length in a variable. The only real factor (in this case) is the difference in speed between accessing an object's property and accessing a variable.

Blender
  • 289,723
  • 53
  • 439
  • 496
  • 4
    The length is **not** recomputed every time you access `.length`. – Felix Kling Aug 06 '12 at 00:07
  • That's what I thought. But from the test, it seems like caching the length speeds up the loop by about 20%. If it's cached either way, why is there a speed difference? – Blender Aug 06 '12 at 00:09
  • The property access is slower than accessing the variable. See: http://jsperf.com/loop-length-caching/2 – Felix Kling Aug 06 '12 at 00:12
  • @FelixKling That makes sense. I found it hard to believe it would. To both Blender and Felix: since it gets such a speed increase, is your recommendation to do it the latter way? – 1252748 Aug 06 '12 at 00:13
  • @thomas: Have a look at Joseph's comment above, that's a common way. That said, browsers are optimising code differently, so whether you gain an advantage also depends on the browser. If you are generally intersted in performance and JavaScript, I recommend this book: http://shop.oreilly.com/product/9780596802806.do. – Felix Kling Aug 06 '12 at 00:17
  • A loop accessing length can't be optimised as much as one accessing a variable. The length property may be modified by the loop, so unless the compiler can work out that length won't be modified, it will have to look it up each time or use other tricks. Also, `theVar` might be changed in the loop to reference some other array or object. – RobG Aug 06 '12 at 00:24
  • @FelixKling I will definitely check that book out. And I sort of think that I'll stick `theVar.length` for now, mostly because it seems least ambiguous and, honestly, one less variable to keep track of that way. Thanks for all the input from everyone to Blender for making that test. Very cool. Cheers! – 1252748 Aug 06 '12 at 00:48
1

Arguably, it's one less pointer to dereference internally, but I have never, ever seen it done the second way in real code. I believe one would have a hard time justifying any performance you might gain.

bkconrad
  • 2,620
  • 3
  • 20
  • 30