>>>>>>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
>
>From my knowledge of language design (which may be somewhat outdated) I would think that it wouldn't make a difference. Regardless of which operation is being called, it would still be an internal procedure/function call.

I don't really understand what you mean here. Is the previous paragraph about VFP or about any language, in general?

Do you mean that an a=b+c is "solved" by a proc/func call inside VFP?

>Part of FoxPro's problem, even with math functions is the lack of strong data typing (eg: You can't programmatically declare and manipulate an integer). I assume (and I realize the dangers in that) that all numeric operations are initially handled as 8 byte double precision FPs.

From some tests I've done long time ago, I would say that some operations on integers (ie: when you use numerical variables with integer values) are handled with 4 byte integers. But I have no way to prove this... :(

Anyway, I'm almost sure that all variables are, in fact, pointers inside VFP. And this adds an overwork anyway.

>That's one reason why iternation structures are so slow. Perhaps the internal coversion to integers for the bit functions are the reason for the difference.

You may be right. I have no more info than you.

Vlad