>>Performance is important to any application, but it is not at the top spot. Having a well designed application that is maintainable is much more important than to optimize everything unconditionally. When performance does matter, there are always other ways of optimizing your app.

>I am missing nothing. Too many have this incorrect belief that speed is not important. Every customer I hear complains about the speed of every programmer.

See the line from me, above yours. I'm not disputing performance is not important. However a well designed application is more important.
Also, it makes no sense to go into great lengths trying to get a few % more performance in a routine that a user only executes a couple of times a day.

Also it is good to keep performance back in your mind when designing a system, but unless the performance is critical it should not be a factor in the design.

>I am also not missing the concept of encapsulating. The forms start out encapsulated. The child form would only participate in the calling form if it's a unit of work. That gives me a very easy "12%"

Thereby breaking the encapsulation. If you expose the data from another form, the form is not encapsulated anymore. If there is a problem in the exposed data, the problem now extents into the called form. Somehow you have a problem in seeing that.

>"Donald Knuth made the following two statements on optimization:
>
>"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%"[3]

Again, as mentioned before, its beneficial to keep performance in mind when designing a system, but still a good design is far more critical than optimizing performance by using dirty tricks. Too often those dirty tricks will bite you in the end. Been there, done that, and never again I'll make that mistake.

I would never use SEEK() in a VFP, SQL SELECT to lookup a value in another table, unless there is A VERY GOOD reason to do so. Just an extra join would do the trick just fine, even if it ends up a few ms slower. Else it creates an incredible mess and a huge potential for difficult to track bugs (imagine what happens if you suddenly decide to put a filter in the SEEK targetted table).

>(He also attributed the quote to Tony Hoare several years later,[4] although this might have been an error as Hoare disclaims having coined the phrase.[5])
>"In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal and I believe the same viewpoint should prevail in software engineering"[3]"

Improvements in design. Improvements in readability, maintainability. Improvements in an efficient GUI, improvements in establishing standards, yes. But trying to hunt for a few percent of performance while it is not sure if the user will ever notice it, is madness.

Nowadays performance of an application is mostly (not all) determined by the database. Just get your database on SQL server. Make sure it is running on appropriate hardware and attack performance problems by optimizing your database. Alternatively supply some caching layer in your application so you do not necessarily need to drag the same list down from the SQL server time after time and you have a solid basis for a well performing application. For the remaining cases which turn out to be a problem, optimize as needed.

Walter,