>I didn't get the impression that CPU measurement was carefully done under either circumstance, but think it fair to assume it was done consistently in both cases.
>It no doubt was a "special" situation, but I don't think that is too relevant to the conclusion offered - their application ran appreciably faster and their CPU measurements showed that both CPUs were in use. I understood theirs was a production application running on dedicated hardware with known application response times.

The thing I was "weary" of was the often mentioned (and IMHO sometimes falsely described ) multithreading of vfp back in this thread: while vfp has more than one thread, "we" can only use one - which means multicores are not helping much in the perf of a an app running just by itself. Since CPU gains will be mostly done by gaining more cores, this is another area where vfp will probably not be able to get the full benefit of.

Getting better support/use of multicores will be interesting - and is one of the problems common to many current scripting/byte-interpreted languages - and for me the most compelling reason for this post <bg>. See the discussion on Python's global interpreter lock for instance as an example for the problems in another language of similar calibre.

>My take is that anything, and especially VFP, is always **very** difficult to benchmark with today's OSs and hardware features and even more so with multi-processing going on.

Agreed - but I was able to control quite a few facets. See inlines...

>- How does one hit a system hard enough with few workstations?
Since it was workstation/datacrunching work, access was to local storage only.

>- How does a partitioned HD differ from separate physical HDs?
We used the same disk type (always as master on the second IDE channel) partioned identically and installed app and tables on the "same" partition as seen from layout perpective from a master backup store.

>- How does just the placement of files (and their extents) on different attempts affect the performance?... as the application progresses?
The disk was formated before each run freshly, probing FAT32 as well as NTFS with different sector sizes with and without disk compression (and a few times even with indexing enabled).

>- How will you even know if a spot used on one HD is a re-assigned track sitting far away on an HD?
Rerun the same batch task.

>- How do potentially varying settings for disk write cache affect things?
>- How does OS caching affect things?... and is it consisteny at each workstation?
>- How does VFP caching affect things?
I experimented with booting into different Memsizes and different sys(3050) and checked against moving most often used tables into a pure RAM disk across diffrent OS. I also iterated over caching strategy settings in the registry as well as the settings for caching behaviour and caching size.

>Windows affords very little control for many factors so it can be a crap-shoot, as I see it. It's one thing to have a problem and set about to solve/improve it, but quite another consistently benchmark anything.

Still very true even when trying to control some factors <g> - but since I was given time to figure out best strategy and machine park to guarantee data crunching turn-around times I am sure of the findings for "my" vfp based tasks which are quite different in character (ranging from FPW based legacy to mostly SQL driven data mining). Not trying to argue - just sharing my expirience.

regards

thomas