Hi Walter,
>Jim,
>
>>Unfortunately VFP only reports to thousandths of a second and I suppose that rounding may have some effect (if rounding is done).
>
>In NT it is even worse: a resolution of only a hundredths of a second.
>
Hmmm, I wonder why??? With chips getting ever faster I would have thought that more precision was in order, not less. There must be some conspiracy in the works < s >.

>>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?
>
>Your test is indeed surprising, but here are some thoughts from my side:
>
>The VFP 6.0 language is significantly richer than the FDP 2.6 . It might be that searching the proper C++ code to execute simply takes more time in VFP. Since the Runtime library has grown significantly this would not surprise me. I can also imagine that much of the internal VFP code has not changed since FPD 2.6, so I would not expect better performance from these commands.
>
Certainly hard to say. My leaning is towards the clock reporting. Something like FPD doing its own while VFP uses some Win functionality. In which case it could well be that VFP is equal or better than FPD but we just have no way to see so.

>Did you do your test in 32 or 16 bit FPD ? what are the results of the other one ?
>
I just ran now under FOXPRO.EXE. All numbers went way up as compared to FPD-32 and very close to the VFP numbers. However, FOR-loop overhead more than doubled even VFP (0.052sec for VFP, 0.10556sec for FPD-16 (0.04978sec for FPD-32)), 'asgn m. both sids' and IF/ELSE/ENDIF both a tad higher than VFP.

Cheers

Jim

>Cheers,
>
>Walter,