You wrote that you were going to re-cook your framework one more time to knock off the rust in the areas that needed a tweaking so you could then port it to the new language.
I would just say that the amount of time you focus on VFP tweaks will not pan out across other languages. I would only focus on putting that framework together to take advantage of whatever language you choose and not be a knock off of VFP. the things you take for granted with VFP in processing don't work the same in other languages. Some things that you thought were the bomb in VFP are only fair in others and yes things that are a PITA to code against are easy in others. YMMV. :) On Fri, Apr 5, 2013 at 1:23 PM, Ken Dibble <[email protected]> wrote: > > 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<http://mail.leafe.com/mailman/listinfo/profox> > OT-free version of this list: http://mail.leafe.com/mailman/** > listinfo/profoxtech <http://mail.leafe.com/mailman/listinfo/profoxtech> > Searchable Archive: > http://leafe.com/archives/**search/profox<http://leafe.com/archives/search/profox> > This message: http://leafe.com/archives/**byMID/profox/5.2.1.1.1.** > 20130405141452.01ffe3a8@POP-**Server.stny.rr.com<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. > -- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN 901.246-0159 cell --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- _______________________________________________ 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/CAJidMYL1W7K+2ttqf067X=j=ecinddop23tty2qxxcar7me...@mail.gmail.com ** 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.
