SNIP
>
>Well, I'm sure that my customer is satisfied (very satisfied) with the current performance. And he certainly will not spend money on such an experiment. :)

So really just another case of "my language can do it better/faster" or even "I can do it faster in the same language".

I would say that most times both such statements will be true. And speed should only be a legitimate issue when the job in question is causing customer or procedural or other problems directly related to (execution) time in the first place! In any other case it's really a 'I'm better than him' statement.

I know for sure, for anything I develop from scratch (i.e. do the discovery/analysis/design in addition to code/test/implement), that they can all be made faster. This is mainly because execution speed is only one factor, and probably not even the prime one, in such cases. Frequently I throw in 'extra' things on the basis that it might come in handy in later enhancements. Always I code 'defensively', meaning that I will put in the SELECT < alias > or USE IN... or IF USED("alias")...ELSE USE... and many other things even though I **know** that VFP's design is to take care of them automatically (for instance SELECT before ENDSCAN or USE IN at termination of a private D/S form, etc). I often use commands/functions known to be slower but also felt by me to be clearer in reading the code OR safer from potential bugs.
And one thing this does buy me, should performance prove to be an issue, is fairly cheap and quick optimization.

cheers

>
>This 'investigation' should suffice for now. Specifically, will ... be outperformed by the C++ equivalents:
>
>FGETS()
>FPUTS()
>CHRTRAN()
>STRTRAN()
>LEFT()
>PADL()
>IF