Why is i— faster than i++ in loops? [duplicate]


Why is i— faster than i++ in loops? [duplicate]

I’ve heard this quite a few times. Are JavaScript loops really faster when counting backward? If so, why? I’ve seen a few test suite examples showing that reversed loops are quicker, but I can’t find any explanation as to why!
I’m assuming it’s because the loop no longer has to evaluate a property each time it checks to see if it’s finished and it just checks against the final numeric value.
for (var i = count – 1; i >= 0; i–)
// count is only evaluated once and then the comparison is always on 0.


Solution 1:

It’s not that i-- is faster than i++. Actually, they’re both equally fast.

What takes time in ascending loops is evaluating, for each i, the size of your array. In this loop:

for(var i = array.length; i--;)

You evaluate .length only once, when you declare i, whereas for this loop

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

you evaluate .length each time you increment i, when you check if i <= array.length.

In most cases you shouldn’t even worry about this kind of optimization.

Solution 2:

This guy compared a lot of loops in javascript, in a lot of browsers. He also has a test suite so you can run them yourself.

In all cases (unless I missed one in my read) the fastest loop was:

var i = arr.length; //or 10

Solution 3:

I try to give a broad picture with this answer.

The following thoughts in brackets was my belief until I have just recently tested the issue:

[[In terms of low level languages like C/C++, the code is compiled so that the processor has a special conditional jump command when a variable is zero (or non-zero).
Also, if you care about this much optimization, you could go ++i instead of i++, because ++i is a single processor command whereas i++ means j=i+1, i=j.]]

Really fast loops can be done by unrolling them:


It can be way slower than

    do_it(i); do_it(i-1); do_it(i-2); ... do_it(i-7);

but the reasons for this can be quite complicated (just to mention, there are the issues of processor command preprocessing and cache handling in the game).

In terms of high level languages, like JavaScript as you asked, you can optimize things if you rely on libraries, built-in functions for looping. Let them decide how it is best done.

Consequently, in JavaScript, I would suggest using something like

array.forEach(function(i) {

It is also less error-prone and browsers have a chance to optimize your code.

[REMARK: not only the browsers, but you too have a space to optimize easily, just redefine the forEach function (browser dependently) so that it uses the latest best trickery! 🙂 @A.M.K. says in special cases it is worth rather using array.pop or array.shift. If you do that, put it behind the curtain. The utmost overkill is to add options to forEach to select the looping algorithm.]

Moreover, also for low level languages, the best practice is to use some smart library function for complex, looped operations if it is possible.

Those libraries can also put things (multi-threaded) behind your back and also specialized programmers keep them up-to-date.

I did a bit more scrutiny and it turns out that in C/C++,
even for 5e9 = (50,000×100,000) operations, there is no difference between going up and down if the testing is done against a constant like @alestanis says. (JsPerf results are sometimes inconsistent but by and large say the same: you can’t make a big difference.)
So --i happens to be rather a “posh” thing. It only makes you look like a better programmer. 🙂

On the other hand, for-unrolling in this 5e9 situation, it has brought me down from 12 sec to 2.5 sec when I went by 10s, and to 2.1 sec when I went by 20s. It was without optimization, and optimization has brought things down to unmeasureable little time. 🙂 (Unrolling can be done in my way above or using i++, but that does not bring things ahead in JavaScript. )

All in all: keep i--/i++ and ++i/i++ differences to the job interviews, stick to array.forEach or other complex library functions when available. 😉

Solution 4:

i-- is as fast as i++

This code below is as fast as yours, but uses an extra variable:

var up = Things.length;
for (var i = 0; i < up; i++) {

The recommendation is to NOT evaluate the size of the array each time. For big arrays one can see the performance degradation.

Solution 5:

Since, you are interested in the subject, take a look at Greg Reimer’s weblog post about a JavaScript loop benchmark, What’s the Fastest Way to Code a Loop in JavaScript?:

I built a loop benchmarking test suite for different ways of coding loops in JavaScript. There are a few of these out there already, but I didn’t find any that acknowledged the difference between native arrays and HTML collections.

You can also do a performance test on a loop by opening https://blogs.oracle.com/greimer/resource/loop-test.html (does not work if JavaScript is blocked in the browser by, for example, NoScript).


A more recent benchmark created by Milan Adamovsky can be performed in run-time here for different browsers.

For a Testing in Firefox 17.0 on Mac OS X 10.6 I got the following loop:

var i, result = 0;
for (i = steps - 1; i; i--) {
  result += i;

as the fastest preceded by:

var result = 0;
for (var i = steps - 1; i >= 0; i--) {
  result += i;

Benchmark example.

Solution 6:

It’s not the -- or ++, it is the compare operation. With -- you can use a compare with 0, while with ++ you need to compare it with the length. On the processor, compare with zero is normally available, while compare with a finite integer requires a subtraction.

a++ < length

is actually compiled as

test (a-length)

So it takes longer on the processor when compiled.