>>>>>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
>>
>>Glad to hear that part of the mystery is cleared up. Still it bothers me that addition is faster than ORing. I guess I've have to be satisfied with math/main processor explanation unless somebody else has a better idea.
>>
>>George
>
>My explanation (no prove that it's true :)): in VFP proc/func call are extremly slow compared to other languages. Since bit operation are handled via function calls, that makes these operations slower than math operations.
>
>Vlad

It all depends on how the VFP compiler handles bitand/bitor/etc. It could optimize out the function call entirely like George said near the beginning of the thread, or it could call a function. Most likely the slowness of VFP is caused by internal interpreter house keeping and not the actual operation being done. For example an integer add takes about 1 clock cycle, but it will problably require many clock cycles to move memory around, get next instruction, do an "instruction" lookup, etc.

Peter