>>A similar application is currently done by me. Some critical person 'suggested' it could be done faster with C++, although the app does a tremendous job compared to .. nothing. I was not sure about it, that's why I started a thread some weeks ago here on the UT.
>>
>>Since then, several thoughts have come to my mind, partially based on the replies and yours too.
>>
>>1) Seeing several thousands of textlines processed per second in a thermometer can be a magical experience, even if the processed file has millions of records. For some vague reason I think it can be far more magical than seeing the whole file processed in a split second. A split-second processing can let the user think that it's all 'no big deal'.
>>
>>2) It is only version 1 of the app. Now we have the potential of creating updates that give 'dramatic' performance improvements. And it are essentially only sales of version 1 that should be the impetus for further development.
>>
>>3) Traditionally, version 1 is the version that proves that technically the job can be done. (Version 2 will be the 'service pack' and version 3 will have a performance boost on board besides new functionality.)
>>
>>4) As in your app, only a part of my app is eligible for C++. However, coding that part in C++ would consume much more time than it has now consumed and I'd also have the problem of optimally integrating it in vfp. Not only speed would boost, the costs for the customer would boost also.
>
>
>Peter,
>
>I believe that you are making a very good point here in which you factor in ultimately the user experience. Even though I get more soda in a 2liter bottle, I always buy the can soda for I like the fuss when opening every can :).
>I agree with your in that every application has pre-requisites; some of the most important being the budget/price and feasability. VFP is a very good tool for proving that the job can be done for that a prototype can be developed and presented to the user/client, using far less time and resources than a C++ solution. Thus, when competing for winning a potential bid, I would choose VFP over C++ to develop the prototype. Of course, we are talking about applications where VFP is suitable for the job, which I understand is your case.
>Even though I am not as experienced with C++ as I am with VFP, I still think that the C++ would be definitely faster. However, after presenting the prototype, would you go back to the client saying that now you're going to have to spend a lot more time to make it work faster?

Certain parts will almost for sure be faster when programmed with C++ or some other lower-level language. Would I tell the customer? Depends... If I notice that the customers are not satisfied with the speed: yes. If I'm the one who's not satisfied with the speed: yes. If nobody is complaining: no, not even if it would mean money (sales). Unless I'm almost broke of course. :)


>Also, absolute speed is most of the time irelevant for it should be related to the user perception and reaction; any user perceived process that takes less time than a mouse click, is most of the time, if not always, irelevant in terms of speed.