Gunnar,

>although i agree with your theory on substracting the time it takes for the loop itself, there is a flaw in that.
>
>the problem here is, that windows constantly is busy. I.E. when ut refreshes the will be some ticks tacken away from the cpu. keeping that in mind, you'll create a 'snapshot' of the time it takes the cpu to process the loop, but it might be a 'bogus' time, same with the calculation command itself.
>
>therefor i belive that with the tools we have available the best is to run the test (like i have it in an earlier message) multible time to obtain an average of 'bottom line' result.

That's why I made the comment about executing enough runs of the test to achieve a set of samples that don't have too much standard deviation. Outlying data points could be caused by something like your virus scanner or defragmenter kicking off during the middle of a run. Here's a basic set of "rules" that I use for benchmarks:

1) be sure you know what you are measuring
2) the test needs to run long enough to be measured accurately
3) enough runs of the test to achieve adequate sampling to reduce statistical error
4) enough runs to give reproducible results
5) not run so long that it will be affected by external factors
6) no unexplainable results
7) the test should involve the smallest amount of code possible

So no the loop time is not significant when comparing time differences, and yes the loop time is significant when trying to determine how much faster one alternative is to another.

Consider this example:

for i = 1 to SomeBigNumber
   ...
   Thing1()
endfor

for i = 1 to SomeBigNumber
   ...
   Thing2()
endfor

Running the tests 10 times yields an average execution time:

Thing1 = 5 seconds
Thing2 = 4 seconds

So you might say Thing1 was abs( 4 - 5 ) / 4 * 100 was 25% slower than Thing2.

But now for the rest of the story as Paul Harvey would say...

for i = 1 to SomeBigNumber
   ...
endfor

The execution time on average for the above "empty loop" is 3.99 seconds. The ... represents other lines of code that need to execute in order for Thing1 and Thing2 to both run correctly, ala the rand() call the other guys were making in their code.

Which means that Thing1 takes 1.01 seconds to execute and Thing2 takes 0.01 seconds to execute. So in reality Thing1 is abs( 0.01 - 1.01 ) / 0.01 * 100 = 10,000% slower than Thing2. Which goes back to rule #1, make sure you know what you are measuring.

>what i mean is, that i wouldn't even say : it takes #,### seconds, because they vary too much. But i would say 'store -x to t' is by far the fastest.

* Footnote: the Thing1 and Thing2 references are intentional, from a father that loved reading Dr. Suess to his daughter ever since she old enough to sit in my lap and read books with me through the times when she could read them to me. Thank you Dr. Suess!