>>>>>>Vlad
>>>>>
>>>>>All I did was to set up two FOR...ENDFOR loops, one that continually ORed the same numbers, and one that added them. By using the same literal values, and having no other code, I felt that it was the truest indicator of actual performance I could find. Any ideas on this?
>>>>>
>>>>>George
>>>>
>>>>I also did this. After that I switched the FORs. I got totally different results. So, I inserted another empty FOR before the other two FORs. Again, different results. I am a little confused and I don't know yet how to interpret these results. :(
>>>>
>>>>I noticed similar behaviors before, but in the other cases I found some explanations. Not this time.
>>>>
>>>>Vlad
>>>
>>>I've tried to simulate what you've done, and with the exception of the first test, there was little difference in the results, regardless of when the operations occurred. Using a 1000 iterations: addition consistently returned 0.003 seconds; OR was consistently either 0.004 and 0.005, with the exception of the first pass. The first pass was 0.037! I'm at a loss to explain this.
>>>
>>>George
>>
>>Always do your tests long enough to have at least 100 ms. The OS is using the CPU also and, from time to time, it uses up to 5ms (no app running) on my computer.
>>
>>Vlad
>
>I bumped the iterations up to 100,000 without a significant change in the results. Addition ranged from a low of 0.273 to a high of 0.306. BITOR() ranged from a low of 0.446 to 0.521. When dividing back by 100 these results seem to match the one's I got previously. The order in which the operations occurred made no difference. So I'm at a total loss to explain why you would get something different.
>
>George

I found the reason: I had a CLEAR at the beggining of the test program. It seems that VFP launches the CLEAR and continues immediately with the next line. This added part of the time required by CLEAR to my first FOR.

I removed the CLEAR command and now everything goes well!

Sorry for the confusion I created...

Vlad