Hi,

Just curious (been in a discussion with somebody else). Is there a performance difference between a FOR loop and a WHILE loop?

Not sure if it will make a difference, but the usage is with three nested loops, iterating over some 300,000 plus data points in total.

Regards,
Graeme

Hi, Just curious (been in a discussion with somebody else). Is there a performance difference between a FOR loop and a WHILE loop?

Yes, for-loop calculates the end value only once.

Not sure if it will make a difference, but the usage is with three nested loops, iterating over some 300,000 plus data points in total.

Mattias

Mattias Gaertner wrote

Yes, for-loop calculates the end value only once.

Ah, thanks for that. Seems so obvious now. :)

Regards,
Graeme

Graeme Geldenhuys wrote

Just curious (been in a discussion with somebody else). Is there a performance difference between a FOR loop and a WHILE loop? Not sure if it will make a difference, but the usage is with three nested loops, iterating over some 300,000 plus data points in total.

I think that in general a FOR loop *can* be faster than a WHILE loop because the iterator variable will be held in a register (if possible) and its start and end values will be calculated only once.

Also, because the iterator variable will be incremented (or decremented) by a constant value it helps the compiler to speed it up further.

If the major time of the loop is needed for the loop body it will not make much difference of course.

Still it makes sense to always use a FOR loop if possible.

Just a note - I learned that for very short "for" loops it may be even a bit faster to count downwards (to zero) rather than upwards if possible, because the comparison to zero is very effiicient. Not sure though whether that still makes a difference on modern processors.

Nitorami wrote

Just a note - I learned that for very short "for" loops it may be even a bit faster to count downwards (to zero) rather than upwards if possible, because the comparison to zero is very effiicient. Not sure though whether that still makes a difference on modern processors.

Testing that on fpc 3.0.0 x86, compiled with -O4 but without looking at the generated code:

program test1;
const   top = $7fffffff;
var     a, i: longint;
begin
   for i := 0 to top do
     a := i;
   writeln(a)
end.

real 0m4.353s
user 0m3.284s
sys 0m0.000s

program test2;
   for i := top downto 0 do
     a := i;

real 0m4.449s
user 0m3.256s
sys 0m0.000s

program test3;
   for i := top downto 0 do
     a := top - i;

real 0m4.671s
user 0m3.264s
sys 0m0.000s

It's interesting that the real (wallclock) and user times are consistently in a different sequence. /If/ the user time is to be believed, there's a very small advantage to counting down even if the sequence you want is ascending (i.e. test3) rather than simply counting up.

On Thu, Feb 2, 2017 at 4:01 AM, Mark Morgan Lloyd <

Not looking at the assembly either, but I'd assume it's because you can do a simple test for zero in the count down case, and have to do a compare against a value and then test the result on count up, which probably takes an extra instruction or two. The optimization can sometimes convert everything to count down as part of the setup of the loop (I know in Delphi you'd sometimes see loops run the other way in the debugger when there was no behavioral change in function). I guess since in your examples the final contents of the a variable after the loop exits depends on direction, then it couldn't do this for the count up loops. Maybe try again with Inc(a) in the body?

Jeff.

Don't forget Repeat Until...

Simply look at the assembler code generated (a big sin)