Tore has a good point, it's probably worth checking all the SETs that are present in VFP but not in FPW such as SET COLLATE.

Is RAM usage an issue? A 32-bit server has a total address space of only 4 GB (assuming no tricks such as PAE). FPW is 16-bit and has a tiny RAM footprint by modern standards. Running 25 simultaneous FPW instances in separate sessions could easily be handled on a 32-bit RDS server.

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 :)).

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.

>This is about the large conversion of a vertical market app that I've been asking about.
>
>We have a large (234 tables, 394 screens) FPW 2.6b for Windows application which runs on a Windows 2008 (32 bit) Terminal Server. The app file, runtime files, data (in simple terms, everything) resides and is run on the same terminal server, so there is nothing going over a network. The number of users varies from 1 at the low end to 25 at the high end. Each of our customers have their own dedicated server.
>
>Users connect to the PICS Terminal Server using an RDP Client (mostly Windows, but some Mac OS) and have an icon on their desktop to launch PICS. Because this is terminal services, they are running as a local user on the same server as the application and all its data is on, so again, as mentioned about, there is no network for the tables/indexes to go across. Everything is local. (I'll add that I'm coding and testing on a stand-alone machine and also see the issues discussed below.)
>
>We've been converting this application to VFP9 and are finding pretty much everything slower in VFP than FPW. We're not surprised that UI is slower; that makes sense given a real Windows application and object-orientation. But we're also finding that code seems slower. We're sharing the same FP2x tables between the FPW and VFP application. We've done a lot of work on the VFP forms to cut down on things like refreshes, but we're still finding even tasks that have no UI are significantly slower in VFP than the same task in FPW.
>
>(Guess I need to say explicitly that, no, we're not using forms created through the Converter that comes with VFP. To be more specific, we have a process that starts with running the Converter, but then we pick everything up and put it on a new form, eliminating the weird formset stuff and creating a regular VFP form. Our tool handles a lot of the rest of the conversion automatically and then we do the final pieces by hand.)
>
>I can't say that it's exactly the same code running in VFP and FPW because we're using buffering in VFP and, in the conversion process, we've made appropriate changes (like eliminating SCATTER/GATHER and working directly on fields rather than variables). I've added logging to some of the things that are painfully slow, and for the most part, it's not that one particular section is slow; it's that each step along the way is a little slow. When I add enough logging, what I see is a few hundred milliseconds here and a few there.
>
>My sense is that if VFP were slower across the board, that would be known in the community (the way we know that instantiating forms is slow). But my first question is whether others have seen that VFP code is slower than equivalent FPW code.
>
>Also, has anyone found particular things that are really slow in VFP that were fast in FPW?
>
>Looking for any ideas about what we might be missing.
>
>Tamar