As Ted always says, you need to test in your environment to determine the best tradeoff between performance and maintainability. Are you deploying applications in a "real-time" environment? Are you working with large arrays inside loops with 1000s of iterations? Then performance overhead is critical and wrapping native VFP functions inside your own wrappers may hurt more than help. OTOH, if wrappers can make your framework code easier to use and maintain, the benefits may outweigh the potential performance decrease.
Yes. However, testing in my environment can't be done very easily. Artificial tests won't really demonstrate the problem; I'd have to revise the framework and then run it in real life situations to see the effect. That would take a lot of time--time that might end up having been spent for no gain. There are other optimizations I can make more easily I think. I know there are places where I iterate arrays to search for things when I could use ASCAN(), for example.
I used to have this discussion with a non-VFP developer who worked for me for a few years. He was always going on about compiled vs. interpreted languages. If you're a human using a computer and it responds to you within a reasonable amount of time when you click something, who cares if it's using a few extra cycles to get there; it's not perceptible to you. If speed is that crucial to what you do you're writing C or whatever the current equivalent of machine code is these days; not VFP.
There's a lot going on when my most-used window opens, because I use metadata extensively to construct the GUI, on top of which a lot of actual data has to be pulled in and displayed. This can take a very perceptible long time. In some situations even after the window is opened, retrieving or saving a recordset takes quite a long time.
There are lots of reasons for this, and I will be looking hard at all of them as I work through this optimizing process, but some of it is due to my extensive use of arrays. Slowing down access to them is probably not the way to go then.
Thanks. Ken Dibble www.stic-cil.org _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
