This was big in it's time because compilers were pretty dumb back then. If you added one to three inside a loop that ran a thousand times then the computer would add one to three a thousand times. Hopefully it would come up with four each time. This was of course very wasteful of time and processing power.
This was actually done deliberately at times in order to get the computer to "wait" for the user. This was not the best way to do thing of course but it was easy and my changing the counter for the loop one could shorten or lengthen the wait. Of course as soon as you upgraded your hardware the timing all changed.
More often this sort of thing happened accidentally when the programmer did not optimize what they are doing. This is an example where very often intermediate variables can be very useful. For example look at the following formula:
price[i] = cost[i] + overhead + markup;
If markup and overhead have constant values or at least values that are not changed inside the loop there will be extra additions that are unnecessary. Modern optimizing computers will see this and "fix" it for the programmer. The compiler will create its own intermediate variable, do the addition and save the results for later use. This greatly improves performance.
Years ago I worked for a company that created a very advanced optimizing FORTRAN compiler. A customer had a benchmark program that it used to test the speed of computers and asked us to run it on our latest computer. The benchmark ran in a split second which was much faster than the large fraction of an hour that they expected. The reason was that the program used a lot of recomputation of constants and other operations that were not good coding practice. For example they added one to a variable 1,000,000 times inside a loop. The compiler looked at that and replaced all of the loops and calculations with simple assignments that saved the results and displayed them. The compiler "solved the problem" and skipped the running the program part.
Today compilers are even better at optimizing code so one might be tempted to suggest that recomputing constants inside a loop is not something one has to worry about any more. To some degree that is true. Still I think that it is better not to depend on the compiler to fix everything for you. It is better in my opinion to present the compiler with the best possible code.
This is the thirteenth in a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.
PingBack from http://blogs.msdn.com/alfredth/archive/2007/01/19/programming-proverbs.aspx