SamSaffron/gist:6503272

## gistfile1.txt
Knuth: Structured Programming with go to Statements
http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts
of time thinking about, or worrying about, the speed of noncritical parts of their programs, and
these attempts at efficiency actually have a strong negative impact when debugging and maintenance
are considered. 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 %.

A good programmer will not be lulled into complacency by such reasoning, he will be wise to look
carefully at the critical code; but only after that code has been identified. It is often a mistake
to make a priori judgments about what parts of a program are really critical, since the universal
experience of programmers who have been using measurement tools has been that their intuitive guesses
fail. After working with such tools for seven years, I've become convinced that all compilers written
from now on should be designed to provide all programmers with feedback indicating what parts of
their programs are costing the most; indeed, this feedback should be supplied automatically unless
it has been specificly turned off.

After a programmer knows which parts of his routines are really important, a transformation like
doubling up of loops will be worthwhile. Note that this transformation introduces go to statements--and
so do several other loop optimizations; I will return to this point later. Meanwhile I have to admit
that the presence of go to statements in Example 2a has a negative as well as a positive effect on
efficiency;a non-optimizing compiler will tend to produce awkward code, since the contents of registers
can't be assumed known when a label is passed. When I computed the running times cited output for this
example, I found that the improvement in performance was not quite as much as I had expected.
	Knuth: Structured Programming with go to Statements
	http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf

	There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts
	of time thinking about, or worrying about, the speed of noncritical parts of their programs, and
	these attempts at efficiency actually have a strong negative impact when debugging and maintenance
	are considered. 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 %.

	A good programmer will not be lulled into complacency by such reasoning, he will be wise to look
	carefully at the critical code; but only after that code has been identified. It is often a mistake
	to make a priori judgments about what parts of a program are really critical, since the universal
	experience of programmers who have been using measurement tools has been that their intuitive guesses
	fail. After working with such tools for seven years, I've become convinced that all compilers written
	from now on should be designed to provide all programmers with feedback indicating what parts of
	their programs are costing the most; indeed, this feedback should be supplied automatically unless
	it has been specificly turned off.

	After a programmer knows which parts of his routines are really important, a transformation like
	doubling up of loops will be worthwhile. Note that this transformation introduces go to statements--and
	so do several other loop optimizations; I will return to this point later. Meanwhile I have to admit
	that the presence of go to statements in Example 2a has a negative as well as a positive effect on
	efficiency;a non-optimizing compiler will tend to produce awkward code, since the contents of registers
	can't be assumed known when a label is passed. When I computed the running times cited output for this
	example, I found that the improvement in performance was not quite as much as I had expected.