Comment by pbsd

From [1], page 8:

  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 specifically turned off.

[1] http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoT...