Long time ago we ran into an oddity under the old VirtualPC running on XP hosting XP VM's. Depending on how the table path was defined (UNC, mapped disk) you had to beef up the VM or let the host (where the file was located physically as well) handle the caching. Not so big a perf hit as you describe, but 1 vs. 1.7 AFAIR. No idea if still an issue under current VM and much better host systems available


>A client is having speed issues with one instance of their vertical market application. At first, their customer was running it on their own local machine. My client has now moved it to a VM in the cloud. In both of those cases, a particular (very complex) daily process is taking 11-12 hours to run. When my client tested on a local machine at their site with the client's data, it took 3-4 hours.
>
>This customer's data set is quite large, with one table getting close to the 2GB limit but not yet there. The client wants to solve the speed problem first, then split the data. I've suggested doing it the other way, but they're insistent. So first question is whether anyone has any experience with VFP slowing down considerably when processing tables that are close to the 2GB limit. (I've never heard any such thing, but trying to come up with theories.)
>
>The client tells me the same process takes about 2 hours on a similar VM for a customer whose data set is about 75% the size of this customer's. That, combined with the 3x speed-up on a local machine, makes me think this is more a configuration issue than application design.
>
>This is VFP 9 SP2 (don't know about hotfixes).
>VM is Windows Server 2008 R2 Standard x64. It has 100GB hard drive with about 14.5GB free. I believe it's configured with 8GB RAM.
>EXE and data are on the VM; no network involved.
>
>We've looked at the obvious things, like SYS(3050) and where temp files are stored and codepages/collation sequences.
>
>Looking for any suggestions.
>
>Tamar