Question

I went throught http://www.youtube.com/watch?v=mHtdZgou0qU speed up your javascript.

So i did this personal speed test:

    var count = 50000000;
    var testDummy;

    // test 1
    testDummy = 0;
    var test1Start = new Date().getTime();
    var i;
    for (i=0;i<count;i++) {
        testDummy++;
    }
    var test1End = new Date().getTime();
    var test1Total = (test1End-test1Start);

    // test 2
    testDummy = 0;
    var test2Start = new Date().getTime();
    var i
    for (i=count; i--;) {
        testDummy++;
    }
    var test2End = new Date().getTime();
    var test2Total = (test2End-test2Start);


    debug(
      "test1\n" + 
      "total: " + test1Total + "\n" + 
      "test2\n" + 
      "total: " + test2Total 
    );

I get not significant results, like sometimes they are even and sometimes not.

My question is, if i use for loop like this: “for(i=count;i--;)” is it really faster ?
Am i doing something wrong in my tests.

Thanks for your help!

Answer 1

(I’d write this as a comment, but it’d be too long.)

First: Worrying about the efficiency of a for loop is almost always a waste of (your own) time. What’s inside of the loop usually has much more impact on performance than the details of how the loop is specified.

Second: What browser(s) did you test with? Different browsers will show different performance profiles; even different versions of the same browser will differ.

Third: It’s not out of the question that the JavaScript engine optimized your loops out of the picture. A JavaScript compiler could simply look at the loop and decide to set testDummy to 50000000 and be done with it.

Fourth: If you really want to split hairs on performance, I’d try for(i=count; --i != 0;) as well as for(i=count;i--;). The former may save a machine instruction or two, because executing the subtraction (in the predecrement step) may automatically set a hardware flag indicating that the result was 0. That flag is potentially wasted when you’re using the postdecrement operator, because it wouldn’t be examined until the start of the next iteration. (The chances that you’d be able to notice the difference are slim to none.)