>>>>
>>>>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?
Vlad,

Yep! If I were a betting man, and I had to wager whether or not the language parser passed mathematical operations off to an internal routine, I would have to say that it did. The complexity of that routine, however, would be another matter.

What I'm about to say is based on personal experience from about 10 years ago, so perhaps what occurs has changed. What I think happens shouldn't have.

Back in the ancient days of personal computing, with languages like BASICA, there was an internal routine that actually did the work of addition, or subtraction, etc. These routines were rather complex. Handling even the simplest addition required numerous lines of assembly code. I happen to have the source code from Atari's 8K BASIC interpreter (it actually did real time syntax checking, something that would be welcomed in VFP, and stored the code as threaded pcode). Anyway, the math routines were handled as a function of the language, not the processor, and literally ran several pages worth of 6502 code.


While I'm sure that processor technology has reduce some of that, the question is what happens at compile time? I submit that there's a routine in VFP to handle this, just as it would any other procedure or function. I think that given macro substitution there has to be. After all, the compiler doesn't necessarily know what the values of the string are going to be, it's up to the internal parser to determine what's what. Given that:

x = 1 + 2

will yield the same result for the variable x as:

lcmac = "x = 1 + 2"
&lcmac

There has to be some sort of internal routine to handle both. In the latter case, the runtime parser handles the string evaluation, and passes it off to the math routine.

Of course, since folks from Microsoft visit this site on a regular basis, and since they know for sure what happens, perhaps one of them would be kind enough to tell us the correct answer to this "mystery". I'd like to know, and I think you would too.

>>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... :(
>

Regarding the loop issue: My hypothesis is based on, unfortunately again, some rather ancient work I did. Back when DOS was still king, and Windows was in its infancy, I wrote a routine in QuickBASIC that had to parse a series of strings, comparing them to others. The strings were approximately 120 characters in length, and the number of strings to be compared were a maximum of 11! (factorial). (That last parenthetical remark wasn't for your benefit, but rather for other readers who may have become confused if I had left the exclamation point as the terminating character of the sentence.)

The routine took seconds on a 286 running at 8 MHz. However, on a 386/20 under FPD 2.0 it took minutes. Realizing that FP's string handling wasn't as good as QB's didn't quite explain the difference. Neither did the fact that QB was executing native code. The only explanantion that was quantifiable was the difference in the number of bytes that had to be manipulated for the respective FOR...NEXT/ENDFOR loops. I assume, and perhaps incorrectly, that this was the main cause. For example, if the routine was taking 5 seconds on the 286 and 1 minute on the 386, and we allow for a 50% degradation because of string handling, and 100% for native code vs. threaded pcode was the rest of the difference, that still doesn't account for the additional time. If, however, you're manipulating 2 bytes for the loop as opposed to 8, that's a 400% difference. And in this type of situation, now you're starting to get close. Especially in view of the fact that the difference (in actual times) was greater than I have indicated.

Of course, VFP may have improved its iteration structures (we all hope) over FPD 2.0. Nevertheless, I have a feeling that it's still using 8 byte FP values. The only way to find out may be to run a test of VB, which allows for the declaration of integer values, against VFP using the same type and size of FOR...NEXT structure.

George