SNIP
>
>I nowadays think the message you reminded of was either a VERY freak special situation
>or a measurement error including other OS-processes - perhaps virus scan or a SQL server.

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.

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.
- How does one hit a system hard enough with few workstations?
- How does a partitioned HD differ from separate physical HDs?
- How does just the placement of files (and their extents) on different attempts affect the performance?... as the application progresses?
- How will you even know if a spot used on one HD is a re-assigned track sitting far away on an HD?
- 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?

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.

cheers

>
>For taxing workstation work WITH a human user hacking at the machine I recommend
>nowadays non-HT double cores, for pure vfp-batch-processing machines WITHOUT
>human keyboard banging I recommend single cores, as the second CPU is underutilized.
>
>Server machines are definitely to be measured by other yardsticks <bg>.
>
>My 0.03 EUR (a tiny bit more than usual <g>)
>
>thomas