>>Erik,
>>
>>I didn't even see a VFP response for the file I/O. Besides, as I've said before, this particular part of the challenge is really weighted towards VB. VB can do the file read directly. VFP would have the additional overhead of converting of the values from character to double precision floating points. That, in and of itself, is a killer. This is not to say that in all areas VFP's file I/O is inferior, just in this particular instance. I think Craig had the idea to read in the entire contents of "War and Peace" and change "Anna" to something else. In something like that, my money would be on VFP.
>>
>>I personally think that the "Challenge" is too broadly scoped to produce any really meaningful results.
>
>I completely agree, and I stated as such in the thread on offRamp. I also proposed a test really similar to Craig's, and it garnered no interest.
>
>I would carry through a benchmark myself, but being a relatively inexperienced VB developer, I don't think I'm qualified to speak for the tool.

As an old "BASIChead" (mostly the Quick as opposed to Visual), from a pure code standpoint I could probably do it, but have very little interest in trying. I will share, however, some (admittedly) old information regarding Fox versus BASIC in DOS.

To start out with, I should note that while QB generated native code and FPD was threaded p-code, the QB version was running on an 8 Mhz AT, and the FPD version was running on a 20 Mhz 386.

What the original and translated Fox programs had to do was compare between 12 and 16 strings, each being 80 to 120+ characters long, character by character. You'd compare one string with the other 11 (or 15) find the nearest match. Take the nearest match, and find the next nearest and so on.

The QB program could do this in seconds. The Fox version took literally minutes. In fact, the difference was so great, that I had to re-engineer the algorithm to get away from this "brute force" approach. (BTW, this recently came back to bite me).

Keeping in mind the difference in processor speeds and the native versus p-code, I came to the conclusion (admittedly not terribly scientific) that the real cause of the difference was the way the different programs handled the FOR...NEXT loops. In QB, which is more strongly typed, I used an integer (one byte at the time). In FPD, I didn't have that option, and I assumed that this was the problem. Working on assumption again, I felt that FPD must be using 8 byte double precision FPs against the one byte that QB was using. This meant that FPD had to move eight times the amount of bytes that QB did for each loop. Whether or not this is still a valid point, I don't know. I haven't done any serious investigation of this since.