3 ms·
"Premature optimization is the root of all evil" I always thought this was a Knuth quote. http://c2.com/cgi/wiki?PrematureOptimization http://c2.com/cgi/wiki?P
by toolslive 12y ago
"Premature optimization is the root of all evil"
I always thought this was a Knuth quote.
http://c2.com/cgi/wiki?PrematureOptimization http://c2.com/cgi/wiki?PrematureOptimization
seems to concur.
- robert_tweed 12y agoIt was, but Knuth called it "Hoare's Dictum". All the evidence seems to suggest it was Knuth himself that coined the phrase though.
- deleted 12y ago[deleted]
- pbsd 12y agoFrom [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/KnuthStructuredProgrammingGoTo.pdf http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoT...
- ivan_ah 12y agoThe "indicating what parts of their programs are costing the most" made me think of the color scheme when working in cython: white (C-fast), yellow (slow). http://docs.cython.org/src/quickstart/cythonize.html#determining-where-to-add-types http://docs.cython.org/src/quickstart/cythonize.html#determi... of course it doesn't tell you anything about the speed of the C code, but I find the line coloring to be a nice UI for showing computational cost.