1691: Optimization

Explain xkcd: It's 'cause you're dumb.
Revision as of 09:09, 8 June 2016 by Flaccinator (talk | contribs) (Explanation)
Jump to: navigation, search
Optimization
Premature optimization is the root of all evil, so to start this project I'd better come up with a system that can determine whether a possible optimization is premature or not.
Title text: Premature optimization is the root of all evil, so to start this project I'd better come up with a system that can determine whether a possible optimization is premature or not.

Explanation

Ambox notice.png This explanation may be incomplete or incorrect: No title-text explanation
If you can address this issue, please edit the page! Thanks.

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 answer, you're prematurely optimizing.

Donald Knuth in his paper "Structured Programming with Goto statements" said:

"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%."

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 describes another time-wasting behaviour common in obsessively perfectionist coders: developing tools to analyse aspects, such as performance, of the software actually required. In the some fields, such as compilers or database design for instance, such tools are useful and productive, but the usage suggested here is more appropriately covered by instinct and common sense.

Transcript

[A flow chart is shown with three boxes connected with two arrows. The first box rectangular:]
Are you prematurely optimizing or just taking time to do things right?
[From the first box there is a short arrow straight down to a diamond shaped box:]
Are you consulting a flowchart to answer this question?
[An arrow labeled "Yes" continues down to the last box, which is rectangularly shaped.]
You are prematurely optimizing


comment.png add a comment! ⋅ comment.png add a topic (use sparingly)! ⋅ Icons-mini-action refresh blue.gif refresh comments!

Discussion

141.101.98.47 08:33, 8 June 2016 (UTC) Yay! First time starting a page's explanation! (Actually second time, but first time I didn't save it in time.) Also, first comment!

Please don't start that again... 162.158.2.138 09:40, 8 June 2016 (UTC)

The flow chart has no branches. It has been optimized, by pruning branches which cannot apply. Are you consulting a flow chart cannot be answered no while consulting the flow chart, so the entire branch structure resulting from a no answer has been eliminated. However, there are many other ways in which premature optimization can take place, and there are some optimizations which are not premature, so this is a robust and fruit laden branch. Since it would be handy to keep that branch in mind, its removal is clearly premature. Therefore, this flowchart has been prematurely optimized.173.245.56.69 11:02, 8 June 2016 (UTC)

I guess that as soon as you are spending time on a flow chart on this question you are not using your time to do things right...--Kynde (talk) 11:11, 8 June 2016 (UTC)
I agree: It's not "if there is any doubt": It's specifically the flowchart. If you are consulting flowchart, you are either the kind of person who does everything methodically and waste gigantic amount of time by it, especially if trying to optimize, or you lack the experience and common sense needed to distinguish when the optimization is premature, and statistically are more likely to optimize incorrect part of code. But note the that most people, when citing the quote, forgot the "Yet we should not pass up our opportunities in that critical 3%." - and result is editor which have noticeable lag on computer which is capable of running 3D FPS game in 120fps. Worse: some decisions, while related to speed of program and therefore optimization, MUST be done early in planing - for example, what data structures will be used. If you start programming with linear list, it may be impossible to switch to B-tree later ; on the other hand, programming B-tree and then finding out the average length of list is 5 is typical premature optimization ; Therefore, you should either use existing library, which will be quick AND quickly written, or spend some time on writing abstract enough interface, so you don't waste too much time on the B-tree but will have option to put it there later without major refactoring. -- Hkmaly (talk) 16:25, 20 June 2016 (UTC)

Is this also an implicit reference to https://xkcd.com/1205/ (Is It Worth the Time)?Dani (talk) 11:44, 8 June 2016 (UTC)

Sigh... One of most misused quotes of all time. The original meaning of "premature optimization" was referring to fine-grained adjustments to assembly that made it much harder to read but a tad faster to run. It's not a justification for choosing a terribly inefficient approach, especially one that will be hard to replace later on. 162.158.91.50 14:11, 5 October 2021 (UTC)