>At our company, we have found something that goes against the conventional wisdom. After putting in huge amounts of memory and fast disk space we were getting very little increase in performance. We had always assumed (and you know what they say about assumming) that disk speed and memory were the bottlenecks for VFP. We noticed that processor utilization was at 100%.
>
>So, since this machine has slots for an additional processor, we slipped an extra in. VFP more than doubled in speed. Both processors are now at 40%...
>
>(BTW when I say "we", I don't have mouse in my pocket. This was discovered by a couple of developers working late so I wanted to share credit.)
>
>I don't know if the last VFP 6.0 patch made it multi-threading, or if it is simply making calls to windows 2000 which is multi-threading. (Any OS masters or hardware experts who want to give more accurate explainations are welcome to.) I'm just happy that we got some of the speed we needed, and wanted to pass this tip along in case it would be useful to someone.

VFP in and of otself is single threaded and single-tasked. However, the OS is itself multitasking, and if other processes, including OS processes, are demanding significant CPU resources, you may have encountered the rare occasion where the VFP app is CPU-bound; the demands placed on the processor by other tasks require that VFP blocks its execution pending other services. It's not unusualy to find that a dual-processor configuration with adequate memory and disk bandwidth can yield around 1.7x the net throughput of a single processor configuration where there are significant demands on the processor - for example, if a graphics app, backend, or processor-intensive background process such as on-the fly compression/decompression or heavy-demand AV processing, or video that places significant demands on the CPU rather than extensively relying on a dedicatged DSP for display management/video decoding are going on.

If you run high-speed/high-demand internet processing (many people think nothing of running high-bandwidth music downloaded from the internet in the background, often on USB speakers that demand CPU atention rather than a sound card's on-board processing) the odds of your system becoming CPU-bounded increases. If you have enough memory to keep VFP resident, and disk I/O bandwidth is not an issue (ie your database fitd neatly in memory) the odds of encountering CPU-bounded environments increases. THis is one reason why I startted adding a second processor to my NT/2K boxes after reaching ~320-384MB of RAM with an adequately fast disk subsystem and high-speed LAN; I'm at the point where I can deliver data faster than a single processor can rummage through it, given that the processor also has all the other support functionality for the OS demanded on it. I'd vewnture to say that my current configuration of dual PII/400s and 384MB RAM can probably crunch more data than a single faster PIII or P4 with similar RAM, because I spend less time in task-switching with two processors than a single CPU would spend, and the overhead of task switching is relatively high.