Hi David

Please pardon me for jumping in. This is not a remark to you, but to everyone who has contributed to this thread.

I am totally amazed about the energy someone can use to save a few nanoseconds. How many thousand years must you use your applications to earn back the amount of time you have spent on this extremely important optimizing problem? <vbg>

>Houston,
>
>In my code lnBaseTime is the time it takes an empty for loop to execute, that amount of runtime should be subtracted from the other loop executions to see how much time was taken by the line of code under test inside the other loops. It is an assumption, I think a prefectly valid one, that that amount of time is essentially constant for the code I posted. lnBaseTime was about 12% of the total execution time, while that washes out when doing simple subtractions of execution times, it does adversely affect % faster calculations between two different tests.
>
>I raised the point because the other benchmarks were mixing the execution time of calls to rand(), which is not negligible.
>
>Given the fact that we don't have easy access to a finer resolution clock in VFP, seconds() really is adequate for these sorts of comparison tests.
>
>The fact that you see variations is why I said you can't use any single result, to be a useful benchmark you need to use an average of at least 3 runs, the more runs the better, you know that whole standard deviation part of statistics. *g*
>
>>

>? seconds() - lnSeconds - lnBaseTime, "test constant assignment"

>>
>>>There's also a couple of other things to note. 1) you have to make sure you are really timing what you think you are timing. lnBaseTime corrects out the amount of time that the base looping takes.
>>
>>I agree, so why are you treating lnBaseTime as though it is a constant? In the code below I commented out the inner-loop processing. The times keep on varying - all over the shop! For example:

1. x * -1                =   0.2810
>>2. 0 - x                 =   0.2660
>>3. m.x * -1              =   0.2810
>>4. 0 - m.x               =   0.2660
>>5. store m.x * (-1) to t =   0.2810
>>6. store 0 - m.x to t    =   0.2810
>>7. store -m.x to t       =   0.2660
>>8. store -m.x to m.t     =   0.2810

The only de facto way of determining how much work is required to execute a line of code is to take a snapshot of CPU clock ticks for the VFP.EXE process just before and just after the line of code of interest and determine the delta (PDH.DLL springs to mind).Whilst your use of lnBasetime is a debatable improvement it is by no means the definitive answer.