>>No offense, Terry, but I wouldn't approach it this way. I'd strive for program correctness and quality before speed. The reason is simple, before I write the code, I have no idea where the bottle necks are.
>>
>>Wouldn't you agree that a correctly designed program executes faster than a less correctly designed one? Is not fast execution, as long as accuracy and usability are not compromised, an indication of a well designed program.
>
>In many cases, yes. In all? No. The first thing you need to define is "fast execution". Instead of "accuracy and usability" I'd substitute, "maintainability" and "reusability".
>
>Correctly designed programs have a tendency to not be as "fast" as incorrect ones. The reason is simple. Correctly designed programs, one's that have "decomposed" or "partitioned" the problem correctly, tend to pay a price in overhead (such as calling another routine, parameters, returns values) when compared to those that write in-line code.
>>
>>But would the user notice?
>>I try to notice!
>
>< g >You're not the user.
>
>>I think that you'll find that you can work a few less hours by concentrating on correct, high quality code rather than speed.
>
>>I'd probably spend my free time looking for loose nuts and bolts - which is what I spend most of my time doing anyway. If it was easy - anybody could do it!
>
>The thing is "anybody" can do it, but "anybody" can't be good at it.

I agree with you, George, especially in this day of very cheap gigahertz CPUs.
Worrying about "fast" need only really be limited I/O in my opinion. Of course there can be exceptions, but they really would be exceptions.

cheers