It looks to me that while($i<$max) is much more straightforward as it explicitly shows that the CPU is going to have to compare those values on each iteration (and nothing else) …

Even though most people seem to believe for should be used in every one of these cases, isn't it much more logical to actually use the while loop, which is clearly more explicit on what it's asking the CPU to do ?

What is your point of view on those aspects when considering performance and precision, including foreach() which hides the $i although it's using it internally anyway ?

If you change the loops to use the same syntax,
while (i>0) { i–; } You’ll see the performance is exactly the same.

But yours is a good hack to know if you are just iterating end to end.

2.703 GHz single core Intel Celeron, 2 GB DDR1 RAM, WinXP Home, 42 running processes (2 instances of Firefox); and the latest stand-alone release player

   For (forward, const): 767
     For (forward, var): 816
  For (forward, inline): 769
         For (backward): 768
 While (forward, const): 826
   While (forward, var): 761
While (forward, inline): 777
       While (backward): 841

   For (forward, const): 765
     For (forward, var): 838
  For (forward, inline): 766
         For (backward): 770
 While (forward, const): 835
   While (forward, var): 749
While (forward, inline): 833
       While (backward): 794

and the modified test:

package
{
    import flash.utils.*;
 
    /**
    *   An app to test the speed of for loops versus while loops
    *   @author Jackson Dunstan
    *     @editor skyboy
    */
    public class ForVsWhile
    {
        public function ForVsWhile()
        {
            var i:int;
            const NUM_ITERATIONS:int = 100000000;
            var iter:int = NUM_ITERATIONS;
            var beforeTime:int;
 
            beforeTime = getTimer();
            for (i = 0; i < NUM_ITERATIONS; ++i) { }
            trace("   For (forward, const): " + (getTimer() - beforeTime));
 
            beforeTime = getTimer();
            for (i = 0; i < iter; ++i) {}
            trace("     For (forward, var): " + (getTimer() - beforeTime));
 
            beforeTime = getTimer();
            for (i = 0; i < 100000000; ++i) {}
            trace("  For (forward, inline): " + (getTimer() - beforeTime));
 
            beforeTime = getTimer();
            for (i = NUM_ITERATIONS; i--; ) {}
            trace("         For (backward): " + (getTimer() - beforeTime));
 
            beforeTime = getTimer();
            i = 0;
            while (i < NUM_ITERATIONS) {++i; }
            trace(" While (forward, const): " + (getTimer() - beforeTime));
 
            beforeTime = getTimer();
            i = 0;
            while (i < iter) {++i; }
            trace("   While (forward, var): " + (getTimer() - beforeTime));
 
            beforeTime = getTimer();
            i = 0;
            while (i < 100000000) {++i; }
            trace("While (forward, inline): " + (getTimer() - beforeTime));
 
            beforeTime = getTimer();
            i = NUM_ITERATIONS;
            while (i--) { }
            trace("       While (backward): " + (getTimer() - beforeTime));
 
            trace('\n');
        }
    }
}

So in the case of the loops in the article, it would seem to me that the JIT would, if it’s doing anything, see the literal 0 as a constant and not the variable NUM_ITERATIONS. It seems unlikely that the JIT would see things the other way around and optimize for the variable over the literal.

To me, it’s still a mystery why forward loops run faster than backward loops. My assumption is that since forward loops are by far more common, this area of performance—on whatever level—has received more attention from Adobe as it represents a far bigger performance win.

It sees that you’re comparing against a constant, and inlines it, making the effective bytecode:

getlocal
pushint
ifge jump

While the bytecode of the backwards loop is effectively (there may be more to it, I’ve noticed that adding gt 0 can speed it up):

getlocal
dup
increment
setlocal
iffalse jump

And the forwards loop is slower in because you used var instead of const making the equive AS3 bytecode:

getlocal
getlocal
ifgr jump

get/set local are slow operations, if you use a var in AS3 you should also see the slowdown as in JS.

The slowdown/speedup in AS2 however is confusing. I can’t come up with a remotely valid reason for this, or even how to do it on the player’s end.

1. Yes, I think they’re wrong. :) If you look at the bytecodes available in AVM2 you’ll see instructions like “increment_i”, “inclocal_i”, “add_i” and so forth. Adobe puts out a good overview. There’s no mention of “pre” and “post”; that is only an order of bytecode generation by the compiler based on the precedence rules of AS3. In the end it is the same bytecode. Still, that’s something I could have been clearer about in the article.

2. My tests didn’t show any difference between “forward while” and “forward for” for AS3. Do you see any difference when you don’t swap the order around? How about when you use Flex instead of CS4? I’m not seeing any difference when I swap any of the tests around.

3. This is good to know! I wonder what accounts for the mysterious slowness “forward for” on AS2…

2. When I move the “forward while” code to the top, it runs slower than the “forward for” (AS3, Flash CS4). It often seems that code running first has a disadvantage.

3. I decompiled the loops; the for and while loops come back exactly the same (AS2 and AS3).