Reply to post:

It depends on what you are doing. If it is a one-off quick and dirty calculation, then the optimization probably doesn't matter.

If it is a system used by hundreds or thousands (or web based, possibly millions of users), then the time invested by the programmer is very cheap, if he can bring down the processing time.

Two examples:

1) a set of financial reporting tools, run every month on a users computers, blocks the computer from all other use during that time. Runtime before optimization: 22 hours, times 250 financial users around the world every month. Optimization: 1 programmer for 2 weeks. Runtime after the optimization: < 3 hours. A saving of 4,750 processing hours per month and around 2,000 man hours of recovered activity involving using their computers. That was 80 hours well invested.

2) an online shop with 4 load-balanced front-end servers and a big back-end MySQL server. When the PayPal newsletter came out and the shop was listed, the whole thing would keel over and die, when around 250 users were spread over the 4 front end servers - the query to generate the front page menu would go from under 1 second to over 2 minutes and the DBA would put in overtime restarting the MySQL database every few minutes.

4 hours of looking at the code, optimizing some decision trees and re-ordering the "WHERE" clauses of the SQL statements, under the load of over 250 user PER SERVER, the menu query was down to under 500 milliseconds and the loading of the front page was under 4 seconds.

They could have thrown a bigger database server and more load-balanced front end servers at the problem, but that wouldn't have been economical, especially when a programmer who understood MySQL and processor architecture was let loose on the code and could get that sort of performance improvement for less than the price of a new SAS drive...

Those are both real-world examples I was involved in. I was brought in to fire-fight both projects, the first an MS-DOS based system, written in BASIC by FORTRAN mainframe programmers and maintained by COBOL mainframe programmers. Having someone who actually understood PC architecture and where the weaknesses were (video output was the biggest bottleneck) made that huge difference.

Likewise, the second one was a couple of year back. The code was elegant and easy for a human to read, but the devs had little of no knowledge of processor architecture (and how to optimize PHP to work more efficiently) and little to no knowledge of optimizing MySQL. Quickly re-ordering the queries and some ifs and loops was all that was required, it was still elegant and easy for a human to read, but more importantly, it was also efficient for a computer to read and execute.