I don't think we're disagreeing, we're talking about different things.
I'm looking at it from the POV of a minimal conversion of this large app. If the motivation is as I think, all that really matters is the service level agreement: the app must offer functionality X and performance Y. As long as those are met the users don't care if it was rewritten in Rust and running on a Raspberry Pi. However, for those doing the work it's probably cheaper and more likely to get a successful result to convert it to VFP.
A side effect is that, being forced to run on new servers, improved hardware is being applied to address any possible performance issues ;)

As I understand it, you're talking about converting to VFP PLUS tactical refactoring to take advantage of new VFP features and thereby improve performance. I gather you've spent a lot of time optimizing VFP apps for speed and I don't disagree with anything you've mentioned below. What I don't know is whether any such refactoring is included in the budget for the conversion of Tamar's app.

>Hi Al,
>
>one of the very few times I have to try to politely disagree:
>
>NOOOOOOOOOOOOOOOOOOO DAMMMMIIIIITTTT!
>Totally wrong mindset!
> ;-)
>
>Lemme explain in very broad paint strokes.
>Why is it typical that next version of vfp runtime is slower
>(with the exception of special tuning efforts like Calvin described for vfp7 NTI search IIRC) ?
>
>Because the runtime has been given more functionality the vfp dev can use.
>
>In FPW I used a key table to generate PK with a record for each table.
>In vfp we were given autoinc as better alternative.
>Running FPW code in vfp misses the possible speedup via autoinc,
>as only 1 table needs to be accessed, as header lock is faster.
>
>In vfp the runtime has not only to do everything FPW does in its smaller
>runtime, it checks for is it in a dbc, are DBC events defined,
>is there an autoinc field defined and jumps over every branch not even available
>in FPW.
>Vfp offers oodles more functionality -you might add a autoinc similar functionality
>in FPW code: define a field name rule, if that such field exists, lock header,,
>read current autoinc, increment as 4byte interger, save in header, unlock, add new record
>set value of quasi-autoinc field in the 4Byte char, update indices and so on.
>
>Nothing totally impossible for perf hungry coders.
>The resulting code probably woul be faster than the
> "old FPW Pk-table" way of doing things -
>but STILL vfp running all that a C level will run rings around
>quasi-identical functionality that "smart coder" implemented in FPW code.
>
>If you continue to code in FPW pattern or paradigma,
>you are thumbing your nose at the effort that went into new vfp version.
>Yes, more than 60% will not really benefit your specific problem.
>
>But there will be something that lifts your total app to a level much harder
>to reach in FPW at a speed you could reach only in C.
>Yupp, sometimes it is necessary, but I like
>most of that handled by Calvin and others at MS.
>
> As Tamar already hinted at USING vfp benefits like buffering
>she is "fair" in not comparing such benefit -
>but *offering and not executing such benefits*
>is one of the reasons vfp code is slower.
>
>Examples: BINARY index, Table buffering vs. Scatter record buffering,
>timers, event binding, standardized hooks in CA, assign/access pattern much better than
>Java / C# getter/setter "standard" pattern, better access to C / WinAPI,
>
>(you can stop laughing at my rant now)
>
>best regards
>thomas
>
>>All versions of Server 2008 went end of life 2020-01-14 (3 years ago). No-one should be using that platform in production any longer.
>>Current versions of Windows Server are 64-bit only and can't run 16-bit FPW apps. FPW apps must be converted to 32-bit VFP to be able to run on a modern Windows platform.
>>
>>If this is your situation, bear in mind the new server(s) your app will run on will be much more powerful than the current one(s). Even if VFP is, say, 25% slower overall than FPW, it will still be faster on the new hardware than FPW on the old.
>>
>>In that case, these performance questions are academic:
>>- You're committed to switching to VFP
>>- You're committed to new hardware
>>
>>So, believe it or not, a fair comparison is actually between FPW on the old hardware vs VFP on new.