Editing 1691: Optimization
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 8: | Line 8: | ||
==Explanation== | ==Explanation== | ||
− | + | {{incomplete|No title-text explanation}} | |
+ | This comic is a flowchart making fun of the difference between prematurely optimizing and just doing things right. Since you're consulting a flowchart to find the answer, you're prematurely optimizing. | ||
− | + | Apart from this main point - do not optimize prematurely - the flowchart in it self is a joke as the question in the first box only result in one arrow, with no options/labels, and by reaching the next box there can only be one answer to that question as you have to be consulting this flowchart to get to that question. The conclusion is that anyone actually trying to find out if they are using ''premature optimization'' are already ''prematurely optimizing''! | |
− | + | The title text's ''root of all evil'' refers to {{w|Donald Knuth}}'s paper "Structured Programming with Goto statements" (1974) in which he wrote: | |
− | |||
− | The title text's ''root of all evil'' refers to {{w|Donald Knuth}}'s paper "Structured Programming with Goto statements" (1974) | ||
<blockquote> | <blockquote> | ||
"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%." | "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%." | ||
</blockquote> | </blockquote> | ||
− | + | *Source: http://web.archive.org/web/20130731202547/http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf (Computing Surveys, Vol 6, No 4, December 1974) | |
− | |||
− | |||
− | + | The title text then just takes the problem one step further back, by spending time trying to determine when you are too soon out for optimization, which is actually just another way of making premature optimization. This time-wasting behavior is common in obsessively perfectionist coders: developing tools to analyze aspects, such as performance, of the software actually required. In some fields, such as compilers or database design for instance, such tools are useful and productive (the 3% mentioned by Knuth?), but the usage suggested here is more appropriately covered by instinct and common sense. | |
==Transcript== | ==Transcript== | ||
− | :[A flow chart is shown with three boxes connected with two arrows. The first box is rectangular:] | + | :[A flow chart is shown with three boxes connected with two arrows. The first box is rectangular:] |
:Are you '''''prematurely optimizing''''' or just '''''taking time to do things right?''''' | :Are you '''''prematurely optimizing''''' or just '''''taking time to do things right?''''' | ||
Line 37: | Line 34: | ||
:You are prematurely optimizing | :You are prematurely optimizing | ||
− | + | {{comic discussion}} | |
− | |||
− | |||
[[Category:Flowcharts]] | [[Category:Flowcharts]] | ||
− |