>>Thanks for that. Do you have any suggestions regarding suitable values for SYS(3050)? I haven't used it before. Is there any good relationship between foreground & background buffer size? Is there a way to estimate what values each/either should be, given physical memory size etc.?
>>
>>regards
>>
>>Mike
>
>
>Mac Rubel had an article in Foxtalk a while back... basically he was setting up different memory intensive tests depending on the physical memory available to the computer.
>
>I tinkered around and tested for a while and realized with the default setting VFP assigns, my system would re-index extremely fast if the program was in the background. When I would put the application on the foreground, the old hard drive would start chugging and it would slow down quite a bit.
>
>This solution seems to be quite good regardless of the memory available:
>
>
>
>*--- memory buffering
>*--- set foreground memory equal to default background memory
>=sys(3050,1,val(sys(3050,2)))
>*--- set background memory equal to about 73% of foreground
>=sys(3050,2,val(sys(3050,1))*.7317)
>
>hope this helps...

Not to argue with this formula, but the default guesstimates taken by VFP are particularly poor under NT and Win2K, where the initial value for SYS(3050) is determined based on the available virtual memory (RAM + swap file space) rather than just physical memory - the behavior os different under Win9x family systems, probably because of differences in the memory management. If you tend to overallocate swap file space (I do this; the usual advice from MS is physical RAM+11MB, and I tend to allow for much more, especially where I have multiple physical disks to allocate swap file space on), you should check the physical memory installed in the system using the GlobalMemoryStatus() Windows API function (there's sample code in the API section of UT demonstrating how to do this) and adjust the SYS(3050,1) to a size smaller than the amount of RAM in the system indicated by the dwTotalPhys member of the structure, and I'd reduce that by at least 10-20MB for the OS and services that will object to being swapped out to disk, and as a general rule, I use dwTotalPhys*.8/(number of VFP sessions expected to run concurrently) to try to minimize the activity on the swap file for the ,1 setting, and half that for the ,2 setting. I'm also fairly insistent about putting enough memory in machines; to me, Win9x means at least 32MB, NT 4.0 and WinME more like 64MB, and I wouldn't use Win2K on a system with less than 128MB on a bet - I use a mix of Pentium II and III systems at home for my development, none at blazingly fast processor speeds (anything from PII/333 to PIII/500 processors, not exactly bleeding edge) but all with at least 256MB of RAM, and all the operating systems I use here see noticable benefits from having more free RAM - I'd venture that they benefit more from an extra 64MB of memory than from a 20% increase in CPU speed (IOW, I'd rather have my Win2K development system run on a PII/400 with 256MB memory than a 750MHz PIII with 64MB of memory.)

These numbers are significantly more than the stated minimum machines for a given OS - Win95 can run (crawl) on a machine with 8MB of memory, as can NT 4.0 with 16MB, but increasing the available memory makes a tremendous difference in the system performance. Ensuring that VFP doesn't try to use more memory than is actually readily available also tends to make VFP apps run better, since the VFP engine can adjust it's cache strategy to fit the amount of actual memory in the system. I typically will try about 150MB on a typical Win2K system with 1 VFP session, a copy of IE, a copy of Outlook and a copy of the MSDN Help running at any time with 256MB RAM, and then adjust from there - this box is actually set at 160000000 for ,1 and 120000000 for ,2 after playing around a little, and I reduce these settings when several copies of VFP are running at once.