Hi Al,

>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 ;)
>
From the "make it run" point of view, ACK &
see reply to Dragan for the context it should be discussed in

The selling point and contract clause in advance should have been:
we can put EOL of the app back a dozen years at least,
we can do minimal conversion (fixing encountered errors)
with perf penatly already compensated by moving to the new HW
(just run the GenScreen/ FPW code compiled under vfp -)

we can stay with basically same GenScreen/FPW code and add some vfp tricks
(modify GenScreen to geenerate code to get form handles on the FPW screens
giving a plethora of tricks with eval(tcVariable), event binding and addobjecting)
but adding new features in FPW code will costs xx% more than in a vfp converted code base
(the handle trick cut typical feature change cost in forms a lot - I guess 40%)

we can move your app to current standards, easing maintainance code in the long run

Getting the "proper sale agreement" is not my forte as well -
I am best at telling customer his wishes are unreasonable or costly
or surprising tech savvy customer who gives me carte blanche and set of tech parameters.

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

From Tamars OP:

>>>(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 FoxPro Windows 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.

I'd say she did not nail down the target parameters hard or defined enough
First step for me would have been finding compilr differences - I remember something about visibility of private array also passed as a parameter where compiled code ran different.
Great if customer has own testing crew ;-)

On that basis discuss further steps for development / port to vfp -
after running vfp compiled FPW code while having FPW as backup
for significant period - much easier to find perf killers when code is still near identical.


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