Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Is VFP (6, SP3) inherently slower than FPD (2.6a)
Message
From
21/03/2000 21:10:51
 
 
To
21/03/2000 18:29:44
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00346811
Message ID:
00348696
Views:
26
Hi Martin,

>Well, the only way I could see to do it was to use a 2x file, let VFP treat it as a free table, and run exactly the same program from both versions. I was primarily interesting in verifying that VFP wasn't radically slower than FPW, so I was satisfied with the results I saw.
>
I agree, on both counts.

>Incidentally, I ran a 100,000-pass loop through few tests using all of the FoxPro versions I have - 2.6 DOS, 2.6 Win, VFP 3, and VFP 6 - with a few common functions. Usually, but not always, 2.6 was faster than either VFP.
>
>            FPD       FPW       VFP3      VFP6
>LEN()       0.181     0.174     0.224     0.270
>UPPER()     0.215     0.216     0.255     0.307
>SUBSTR()    0.279     0.274     0.295     0.343
>ROUND()     0.410     0.353     0.346     0.359
>%           0.366     0.320     0.325     0.447
>
>I have no idea what this means, frankly. I don't think it's the clock, though.
>
No, I've eliminated the clock too. Looks like we'll probably never learn why either.

Cheers,

Jim N

>Martin
>
>>Hi Martin,
>>
>>Interesting numbers you got too. But it has to be real difficult doing comparisons of table access timings between FPx and VFP because VFP has so many more variables/options involved.
>>
>>As I said in another reply, I'm leaning as much towards 'clock reporting' differences as anything else so far.
>>
>>Cheers,
>>
>>Jim N
>>
>>
>>>
<b>
>>>>Type of Command   100K in FPD    100K in VFP
>>></b>
>>>>
>>>>assign w/o m.     0.11500 sec    0.226 sec
>>>>assign with m.    0.10642 sec    0.272 sec
>>>>asgn m. both sids 0.19310 sec    0.314 sec
>>>>
>>>>IF/ENDIF          0.22485 sec    0.472 sec
>>>>IF/ELSE/ENDIF     0.23858 sec    0.477 sec
>>>>
>>>>simple IIF()      0.24116 sec    0.462 sec
>>>>
>>>>logical by expr   0.16907 sec    0.387 sec
>>>
>>>>Pentium II, 233mhz, 128meg.
>>>>
>>>>Since each is for 100,000 executions, my concern is tempered. But it still seems to be a step in the wrong direction.
>>>>
>>>>Is there a sensible explanation for this?
>>>
>>>I did some VFP6SP3 performance tests against FPW26 awhile back, using COUNTs and simple SELECTs, with 10,000 executions on a Pentium 166 with 64 meg and 30,000 executions on a Pentium 266 with 128 meg. What I found was:
>>>
>>>1. if the table being COUNTed or SELECTed against was USEd outside the loop, VFP was as fast as or faster than FPW, but if the USE was inside the loop (or for the SELECT, if the table wasn't open at all), FPW was faster;
>>>
>>>2. when the loop was set up to use Rushmore VFP was faster, but without Rushmore FPW was faster;
>>>
>>>3. VFP's advantage over FPW was much more pronounced for the 10,000-execution loop - a factor of 15-20, versus a factor of 2-10 for the 30,000 loop.
>>>
>>>My assumption at the time was that there's more overhead in VFP when opening or searching the table itself, but that index searches and the actual command execution is faster in VFP. Based on what you got, it looks like the number of passes in the loop matters, too.
Previous
Reply
Map
View

Click here to load this message in the networking platform