>On the other hand 32-bit VFP can use much more RAM, and as I understand it, is not limited by default. A 32 bit app can request and be allocated up to 2 GB of RAM. This can be an issue if you're running a lot of 32-bit app instances on a 32-bit RDS server.
>
>If you're not already doing it you could experiment with setting VFP RAM usage limits somewhere between 256 and 511 MB. ISTR Thomas Ganss and John Ryan saying there's not much benefit going over 256 MB and that allowing 512 or higher can actually hurt performance (guys, correct me or elaborate if my memory is faulty :)).

You are correct, unless you have SQL joins. Large RAM can keep intermediate files in memory and get a heavy boost. but the more you use xBase style of data access or single table SQL as in CA updates or deletes on single tables, you can eek by on tiny memory.

>If an RDS server gets starved for RAM then:
>- running apps need to page to disk more often
>- there is less available free RAM to be used for disk cache
>== slowness
>
>You can monitor RAM memory usage on the server when running FPW instances vs VFP sessions to see if this might be an issue.
>
>If you don't find a quick fix through configuration or settings, it would be helpful if you could give some general idea if the slowness you're seeing is CPU or I/O.
>
I wonder if the SMB / oplocking might play a role, as early vfp was tweaked to run on SMB1. I don't remember much on networking issues with FPW - as it had no views or buffering, local caching was not so important. Dunno how a grid/browse was implemented, and if reprocess might hit vfp heavier as it "expects" local data sets.