I can give you only data from wayyy back:

We were tasked to rewrite a large application from FPW to vfp, starting at vfp6 and moving up to vfp9. There was one REALLY speed critical subtask I ended up baby-sitting for a few years and others I had to optimize.

Before project started a few subtasks were run to see if vfp6 was in same ballpark as FPW.
Result: vfp6 was slower across the board, data/table operations 5 - 15% slower, screen drawing/handling 15 - 35%..

vfp7 added minimal runtime to that, on 8 and 9 measurements were skipped.

Was accepted with promise to optimize worst cases and glowing praises for architecture benefits.

Architecture was layered and flexible - but sucked at speed... But with a few ham-handed changes became acceptably performant, as added features were perceived. But raw speed of having 2.x forms against table fields or scattered table fields of FPW was hard to beat. Speed difference was greater when running in the low memory set for FPW, when more memory was given, difference was smaller but FPW was still faster.

Tinker with memory to find a baseline good for vfp (smaller for xBase typical code, more memory if SQL is used in vfp for many things now) - including views and CA to give you table buffered cursors. Force garbage collection when reasonably certain user will look before next button. Check the # of open tables - when you switch from using FPW tables with scattered fields even to single record cursors, you will need lots of work areas more. Too many work areas will slow down vfp, similar to too many forms or too many objects - but work areas are "heavier" and degrade much sooner..

Unless the FPW code is already optimized I'd not worry too much - with vfp you can find those slow spots much faster (although coverage profiler is often leading you astray), use event binding for methods and sprinkeled in C timing for functions to get better runtime ideas.

Use timestamps or counters as timestamp surrogate if buffering, perhaps joining PK and TS for lookup on update conflict, checking only the index.
.
//upd:
What Tore wrote!
Also: switch PK to Integer, autoinc if possible. cuts down a bit on next PK from key table...
use datetime, use binary indices if FPW uses a deleted() index (which sometimes helps, sometimes hinders), but with BINARY will be faster (less if no physical LAN involved, but still less data moved)
Low hanging fruit, but saving file moves or bytes in index files is always good.

>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