Comments on: Unroll your loops!

By: Theo

Theo — Sun, 21 Sep 2008 09:30:34 +0000

The lesson here is that you shouldn’t optimize while you refactor.

By: Severin

Severin — Sun, 21 Sep 2008 01:37:07 +0000

Well, I’d say your guts were right, at least if this code is really a performance bottleneck: if you’d do let’s say a 1000000 iterations on doTheThing(), then the first thing would be substantially faster done, at least if there’s only a little bunch of items to iterate locally. Why? Because method calls in AS3 are much slower (I’m talking of factor 100) than assignments. But I agree, that – if you wouldn’t have to do the thing many, many times – there’s only a theoratical difference. Ehm, hope my 2 dirty cents made themselves kind of clear ;)

By: bjorn

bjorn — Mon, 08 Sep 2008 06:51:00 +0000

Good one Theo, my gut told me the same thing yours did .. but when thinking about it I can’t see why I thought setting up a loop should be so costly :-)

By: Theo

Theo — Mon, 08 Sep 2008 05:42:48 +0000

You’re right of course, but it’s also a very different example. The point of mine was that the loop body wasn’t interdependent. In your example the parts don’t do half the work. It’s less likely that you’d want to refactor a piece of code that worked like that because the parts depend on each other. I’m not claiming that any loop can be split apart and maintain the same time complexity.

By: ronen

ronen — Sun, 07 Sep 2008 21:17:09 +0000

Its all a matter of what is the operation on which your measuring the runtime (summation and max operations in your case), lets imagine a case where you have method calcA and calcB, each cost o(1) used in the following loop

int acc=0,temp=0; for(int i=0;i

The run time is o((1+1)n)=o(n)

Now lets unroll this loop into two separate loops:

int methodA(int k){ int temp=0; for(int j=0;j<=k;j++){ temp+=calcA(j); }
return temp; }

int methodB(int n){ int acc=0; for(int i=0;i return acc; }

for each calcB we calcA i times, which makes the runtime: ((1+1) + (1+2) + .. + (1+n-1))=(2+3+..+n) = (n (2 + n)) / 2 = (2n+n^2)/2 = o(n^2) This is quadratic time instead of linear time! Now for simple un-rolling its visible and can be prevented by a worthy programmer the problem is that in real life code isn't as clear as in this case, still you are correct since usually most of the code doesn't reside within the 10% in which the program spends 90% of its processing time (therefor making optimizations worthless).