Comments on: JavaScript loop performance

By: Robert Nyman

Robert Nyman — Sat, 11 Oct 2008 18:14:16 +0000

Philippe,

Thanks for you input!

By: Philippe Lhoste

Philippe Lhoste — Sat, 11 Oct 2008 08:56:36 +0000

Interesting.
I am not fan of micro-benchmarks, even less those testing empty loops! You don’t know if the compiler (or interpreter) detects them and optimize them.
So I ran a little variation of your code, just putting divs[i] = something with something changing between each loop ("Jeh" + i and variants).
Tested on FF3, IE6 and Opera 9.26. It greatly reduces the influence of the loop method, which is logical, but still shows a trend. Actually, it corroborates your finding: divs.length is still the slowest method! And pre-assigning the length is still the fastest. Note that the for with divs[i] can be optimized as: for (var i=0, d; d=div[i]; i++), using d instead of divs[i] in the loop, so the test have an interesting side-effect, and a light speed gain (only one loop up).
Personally, I am not fan of “assign-as-test” but it leads here to results close of your loop3. And unsurprisingly, it is near of the equivalent while loop.
But it is dangerous: as pointed out, if the content of the array can be interpreted as false, it stops the loop! You can still do an explicit (d=div[i])!=null without time penalty.

So, I will stick with an explicit comparison with a pre-assigned length variable.

Note: in the increment part of the for loop, i++ and ++i has no importance, you can even write i += 1 if you wish (probably slower), the interpreter will just look at (and use) the resulting i.

By: Robert Nyman

Robert Nyman — Wed, 27 Aug 2008 11:08:08 +0000

Steve,

Yep, IE is so far behind their competitors, in any way imaginable…

By: Steve

Steve — Wed, 27 Aug 2008 10:26:03 +0000

Wow, thanks for the speedy reply.

I stuck with doing the nextSibling approach in IE and 3rd loop in everything else. The loop 3 seemed to work fine in IE as well. My problem was accessing other DOM elements in each iteration - just had to cache these and it was all good. Although its off the topic of the post, there was never a problem in anything other than IE even before caching (execution < 2 secs) while IE was taking more than 30 secs for the same function. I guess the optimization of the other compilers is just better

By: Robert Nyman

Robert Nyman — Wed, 27 Aug 2008 09:58:19 +0000

Luc,

Thanks!

Morris,

I know that variable declarations goes for the entire function and not just the loop itself. But I can’t see how this would matter here?

Greg,

Well, they might be, but my guess is that the results would be about the same.

Steve,

Actually, it returns a HTML collection in all web browsers (like a light-version of an array). So, I’m not sure IE works the way you describe it, meaning that it would probably not be necessary to loop through the childNodes. In my experiences, at least with IE, getting childNodes has been fairly much slower than, for instance, getElementsByTagName.

However, I can’t give you a definitive answer; I guess it all comes down to testing, testing, testing.

By: Steve

Steve — Wed, 27 Aug 2008 07:59:27 +0000

Hi,

I wondered wether it has to do with the way that collections are implemented in different version of javascript. The DOM method getElementsByTagName returns an array in firefox etc. but in IE it returns a linked list. When you are setting up your loop as

index=0; index < divs.length; index++

IE needs to loop through the whole list to calculate the length for each iteration giving you O(n2). Please could someone confirm this for me.

My other question is that if this is in fact true, when you index the div in the ‘array’ as divs[index] does IE need to loop through the linked list to find the correct position giving you O(n2) again? perhaps its better to get the parent element and then loop through the child nodes using while (currentNode.nextSibling) {
//do stuff
currentNode = currentNode.nextSibling; }

Any info would be greatly appreciated because I’ve having some trouble with this for a while

By: Greg

Greg — Tue, 22 Jul 2008 19:15:24 +0000

Another observation, loop 2 will fail on sparse arrays.

By: Greg

Greg — Tue, 22 Jul 2008 19:14:03 +0000

I notice that you’re looping through an HTML collection, i.e. the result of getElementsByTagName(). My understanding is that this is not a true native JavaScript array. I wonder if the results would be different if you transferred the contents of the HTML collection into a native array prior to doing the benchmarks.

By: Morris

Morris — Wed, 16 Jul 2008 03:43:38 +0000

Robert, Noevov, Gerben: how variable declarations work in Javascript is commonly misunderstood — the following do not do what you might expect:
function test1() { for (var i=1; i<2; i++) { } alert('test 1: i=' + String(i)); } function test2() { for (i=1; i<2; i++) { } j=10; alert('test 2: i=' + String(i) + ' window.i=' + String(window.i) + ' window.j=' + String(window.j)); var i; } test1(); test2();
The rule is that a var declaration anywhere in a function applies everywhere within a function. This means:

Making the var declaration in the for loop doesn’t mean the variable is scoped to that loop - it is scoped to the function (as per test1 - which alerts i=2).

A local variable can be declared after it is actually used (as per test2 - which also alerts i=2).

By: Luc

Luc — Thu, 10 Jul 2008 10:37:10 +0000

Here are some additional results for you. The Array.forEach is build into .NET javascript. My timings are over 2,000 elements and I am doing the following statement in each for loop:

div.innerHTML = ‘A’;

1) Loop: for (var i=0; i 437

2) for (var i=0; divs[i]; i++)
407

3) for (var i=0, il=divs.length; i 406

4) for (var div in divs)
422

5) Array.forEach(divs, function)
422

SO THE WINNER IS (3) which is roberts pick. It would use slightly more more memory though (barely).

By: Robert Nyman

Robert Nyman — Wed, 30 Apr 2008 11:45:25 +0000

Christian,

Thanks for the tip! I haven’t read that post of yours, actually, but it was very very similar.

The benchmarking is extremely basic, so I agree that this should just be a base for more extensive testing to be done.

By: Christian Heilmann

Christian Heilmann — Wed, 30 Apr 2008 10:22:43 +0000

I wrote a strinkingly similar post about different loops and their impace on performance and ease-of-coding last April, but found that benchmarks done this way are pretty useless.

I got a lot of comments though, and there was some really good information in there.

By: Robert Nyman

Robert Nyman — Mon, 28 Apr 2008 20:25:20 +0000

Ricardo,

Interesting! Thanks for sharing.

By: Ricardo

Ricardo — Mon, 28 Apr 2008 19:33:12 +0000

Hi,

In an experiment I’m working on I’m generating 2400 divs and setting it’s class with a loop. There is negligible difference between these 3 techniques you showed, loop 2 lags around 100ms behind the others (total time 1.2s). I usually set a global var for length if it’s used across many functions and the array won’t change.

The thing is, using a while loop instead of for, the total time comes down to 0.8s. Also tried loop unrolling/duff’s device with no effect, so I’m staying with while for now :]

By: Robert Nyman

Robert Nyman — Fri, 18 Apr 2008 15:16:56 +0000

Fredrik, liorean,

Those are two interesting approaches. I haven’t tried them out yet, but in theory they look interesting!

When it comes to timers and actually doing something within the loop, I’m well aware that it would change the results, but at the same time, then the timers can be thrown off by some irregularity in what’s done within them.

So, please see my tests as a base for doing more and more extensive tests.

By: liorean

liorean — Fri, 18 Apr 2008 12:53:42 +0000

Oh, and your post preview doesn’t quite match the real posted comment, I see…

By: liorean

liorean — Fri, 18 Apr 2008 12:51:56 +0000

Robert: There's at least one other loop construct I would recommend: while(elm=coll.item(i++))In this syntax you use the elm variable inside the loop body instead of using divs[i] as your last example would require. (You can of course consider this a variation of second loop, which I'd write as: for(i=0;elm=divs.item(i++);&#x29Why do I use .item? IIRC there are cases where coll[i] throws an exception but coll.item(i) instead returns null. It's browser dependent though - some browsers actually return null for the hash access too.Also, I'd want to see you do those timings with an explicit lookup in each of the loop bodies, because in real live code you're not going to loop through these collections without actually using the elements for anything, and basing your timing of each example where you're actually not doing the most expensive part of the loop invariant which is always there in real world situations scews the results.

By: Fredrik

Fredrik — Fri, 18 Apr 2008 11:43:35 +0000

Have you tried profiling the prefix ++ notation?
i.e: for (var i = 0; i < len; ++i)
in theory it should be slightly faster since it only does exactly what you want, incrementing the var, Not incrementing and then returning the previous value..

By: JavaScript loop performance | gosnip.net blog

JavaScript loop performance | gosnip.net blog — Thu, 17 Apr 2008 12:21:20 +0000

[...] Nyman, the original author of the perfect little JS library, DOMAssistant, has done a little loop speed test and has come to a very useful conclusion that saves a lot of processing time. Next time you do a [...]

By: links for 2008-04-15 | Libin Pan

links for 2008-04-15 | Libin Pan — Tue, 15 Apr 2008 06:46:43 +0000

[...] JavaScript loop performance - Robert’s talk - Web development and Internet trends JavaScript loop performance (tags: AJAX javascript performance) [...]