6 ms·

This is not an example of premature optimization. It is an example of guessing at the problem and missing the mark. It is best explained by Donald Knuth himsel

by Genbox 4y ago

This is not an example of premature optimization. It is an example of guessing at the problem and missing the mark. It is best explained by Donald Knuth himself. The full quote is: > "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.". Source: Structured Programming with go to Statements by Donald E. Knuth. http://web.archive.org/web/20130731202547/http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf http://web.archive.org/web/20130731202547/http://pplab.snu.a...

throwaway0asd 4y ago
Perhaps a better understood paraphrase: Never guess at performance, and don’t measure for performance until the application works.
- djmips 4y ago
  1st part. YES. 2nd part. NO. If your end goal needs to meet a certain mark then you need to be measuring as you go. If you are headed down the wrong path, by not paying attention to perf you'll end up bogged down rewriting systems that 'work' but they were never going to be fast enough. I've been through this headache too many times now to not get a little irritated when projects don't keep perf and memory usage on the same importance as 'working'. This often manifest by developing on much more powerful hardware than will be shipped on... All you need is the measure part. Then you won't do the evil thing of optimizing something that makes it more brittle and hard to maintain etc.
  - s1k3 4y ago
    Well it’s not like you don’t keep it in mind. Your project has some baseline performance need and you should be building with the common practices and paradigms you used to build the other parts. The point is, don’t try to guess which part might need optimization tweaks. Write it first and then prove you need to spend extra time improving something.
    - djmips 4y ago
      But don't write it all first, that is don't wait until your shipping. I mean if you are trying to be first to market maybe that changes things. Everyone's developing different things in different markets but in my experience developers tend to hold onto that particular mantra, and it turns into wait until the last minute to actually check perf. See other comment about the immaturity of the industry which I agree with.
  - throwaway0asd 4y ago
    I agree in theory but not in practice. Most developers have no idea how to measure the performance of a software product either in code units, libraries, features, or the product as a whole. Worse, they really have no idea what to measure. This is even after you’ve passed that tremendous hurdle that you need measurements not assumptions. A large part of that is due to the immaturity of software as a profession relative to other professions. Measuring things takes tremendous effort and many developers don’t want to challenge their deeply held assumptions of how things work. Often when you present performance measures to developers they will invent an excuse to throw the data out if they don’t like the conclusion.
    - ncmncm 4y ago
      If performance matters, you hire the subset of programmers who do have an idea about performance, and who even get it right before measuring.
    - djmips 4y ago
      Sigh, this is true. Better training and better tools can help make obvious their mistakes but I don't know how to combat the dogma. I've often been shocked how almost superstitious developers are - you'd think developers would have a more scientific approach but they are just as likely to chase after ghosts than optimize what needs to be optimized.
tejohnso 4y ago
Ya that paragraph is ripe for cherry picking that often quoted nugget. But right after it is "we should not pass up our opportunities in that critical 3%". And further along, "the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail." That one I think is the most important. You don't even know what you should optimize until you measure. You could end up spending a lot of time and energy on the wrong problem.
- Brian_K_White 4y ago
  It's like the problem is the ambiguous definition of "premature". I think by itself the phrase is taken to mean to keep the code high level and abstract as long as it might still need to change, and then only optimize once it's overall structure is established, because once you start optimizing for performance you are carving stone and destroying flexibility. But the full context shows that the word "premature" in this context means to say that it's premature to optimize before you even know what to optimize.
- ncmncm 4y ago
  Those of us who have been doing this a long time develop an awareness of our "hot path", and defend it against encroachments. Work keeping speed bumps out of our hot path is not premature.
- jandrewrogers 4y ago
  Performance is not a primary objective for most software. For the subset where it is, most performance is architectural; if you don't design for performance from the outset then you'll never be able to add it later. People that have been in the performance business a long time, the kind of people you want if performance matters, can estimate the performance of code without running it to a degree of accuracy that is surprising to people with no performance engineering experience. Not understanding the relationship between code and performance is not the same as no one being able to understand the relationship between code and performance. It is a specialized discipline but people in it don't need to measure code for macro-optimization purposes. You still need to measure some things for micro-optimization purposes, but even there you'll find savants that really don't need to. Naturally, there is an element of many developers overestimating their ability to estimate code performance. That is not universal though. I've worked with developers that could consistently and precisely describe the performance characteristics of code on real hardware without running it. A lot of computer science is premised on this being possible. Acting like this is unknowable is doing a disservice to computer science as a discipline. If you understand how code interacts with hardware then performance is deterministic and obvious. There are degrees, of course, but some developers have a deeply intuitive understanding of these relationships.
Archelaos 4y ago
But even that has to be taken with a grain of salt. There are kinds of critical code that are hard to identify. Think of the infamous O(n^2) algorithms which are not identified unless you measure high values of n. Or not well coordinated threads that slow down a programm only on specific occasions.
- junon 4y ago
  Yes, but conversely, there are cases where O(1), O(N) and O(N^2) are all perceptually the same in all cases of a particular program. There's a bit of an art to determining what is critical and non-critical.
zionic 4y ago
>A good programmer will not be lulled into complacency by such reasoning And that's the crux of it. Donald neglected to understand that most programmers will takeaway "optimization is bad" and all the subtleties of his point will be lost. Then we get things like electron (ducks for cover)
- ummonk 4y ago
  Donald was also writing at a time when all languages were close to the metal and optimization meant using various tricks (or writing critical portions in assembly) to improve performance.
  - FpUser 4y ago
    >"when all languages were close to the metal" That writing was 1974, Lisp had already existed.
    - ncmncm 4y ago
      And even caches. Though we called it "core", back then. Main memory was disk, tape, or drum, and cache misses caused page faults, if you were fortunate, or you had to roll in overlays yourself. Nowadays RAM is as inaccessible as disk was then, and you swap 64-byte pages, sometimes with network negotiations with remote (NUMA) cores, all in hardware.
- Ygg2 4y ago
  > Then we get things like electron We get electron because it's a batteries included (and remote and TV) cross platform GUI. And has a huge talent pool, and acceptable performance for most users.
Someone 4y ago
I agree. This is immature optimization. Back to ”Premature optimization is the root of all evil”: I think that’s a bad statement. The only thing that says something there is all, and it is incorrect. “Premature (noun) is the root of evil” is true for about every noun you can out there. “Premature design is the root of evil”, “Premature programming is the root of evil”, “Premature debugging is the root of evil”, etc. Adding all implies there aren’t other things that are (in this context) roots of evil. I don’t think that’s true. As an example, one can spend excessive amounts of effort thinking about, or worrying about the ‘beauty’ of source code.
- osigurdson 4y ago
  I suspect when Knuth first came up with this phrase, he didn't expect it to be taken as gospel.
hyperpallium2 4y ago
He's making a more general statement, with "root of all evil", that improving some aspect of something without understanding its effects on the whole outcome, is literally the root cause of evil in the world, in general. Winning the battle but losing the war. Not seeing the forest for the trees. Getting lost in the weeds. Unenlightened self-interest. Not hyperbole, but a particular instance of a general concept. But on code optimization, k deeply nested loops are not a bad guide to O(n^k), and a candidate for optimization. That said, I once cached something that obviously needed to be cached - so obvious in fact that a deeper level in the system already cached it.
worik 4y ago
The original biblical quote it riffs off is often, mostly, misquoted as: Money is the root of evil. It actually is (give or take for translation) "For the love of money is a root of all kinds of evil." Timothy 6:10 The love... A root... All kinds...

by Genbox 4y ago

throwaway0asd 4y ago

Perhaps a better understood paraphrase: Never guess at performance, and don’t measure for performance until the application works.

djmips 4y ago
1st part. YES. 2nd part. NO. If your end goal needs to meet a certain mark then you need to be measuring as you go. If you are headed down the wrong path, by not paying attention to perf you'll end up bogged down rewriting systems that 'work' but they were never going to be fast enough. I've been through this headache too many times now to not get a little irritated when projects don't keep perf and memory usage on the same importance as 'working'. This often manifest by developing on much more powerful hardware than will be shipped on... All you need is the measure part. Then you won't do the evil thing of optimizing something that makes it more brittle and hard to maintain etc.
- s1k3 4y ago
  Well it’s not like you don’t keep it in mind. Your project has some baseline performance need and you should be building with the common practices and paradigms you used to build the other parts. The point is, don’t try to guess which part might need optimization tweaks. Write it first and then prove you need to spend extra time improving something.
  - djmips 4y ago
    But don't write it all first, that is don't wait until your shipping. I mean if you are trying to be first to market maybe that changes things. Everyone's developing different things in different markets but in my experience developers tend to hold onto that particular mantra, and it turns into wait until the last minute to actually check perf. See other comment about the immaturity of the industry which I agree with.
- throwaway0asd 4y ago
  I agree in theory but not in practice. Most developers have no idea how to measure the performance of a software product either in code units, libraries, features, or the product as a whole. Worse, they really have no idea what to measure. This is even after you’ve passed that tremendous hurdle that you need measurements not assumptions. A large part of that is due to the immaturity of software as a profession relative to other professions. Measuring things takes tremendous effort and many developers don’t want to challenge their deeply held assumptions of how things work. Often when you present performance measures to developers they will invent an excuse to throw the data out if they don’t like the conclusion.
  - ncmncm 4y ago
    If performance matters, you hire the subset of programmers who do have an idea about performance, and who even get it right before measuring.
  - djmips 4y ago
    Sigh, this is true. Better training and better tools can help make obvious their mistakes but I don't know how to combat the dogma. I've often been shocked how almost superstitious developers are - you'd think developers would have a more scientific approach but they are just as likely to chase after ghosts than optimize what needs to be optimized.

tejohnso 4y ago

Ya that paragraph is ripe for cherry picking that often quoted nugget. But right after it is "we should not pass up our opportunities in that critical 3%". And further along, "the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail." That one I think is the most important. You don't even know what you should optimize until you measure. You could end up spending a lot of time and energy on the wrong problem.

Brian_K_White 4y ago
It's like the problem is the ambiguous definition of "premature". I think by itself the phrase is taken to mean to keep the code high level and abstract as long as it might still need to change, and then only optimize once it's overall structure is established, because once you start optimizing for performance you are carving stone and destroying flexibility. But the full context shows that the word "premature" in this context means to say that it's premature to optimize before you even know what to optimize.
ncmncm 4y ago
Those of us who have been doing this a long time develop an awareness of our "hot path", and defend it against encroachments. Work keeping speed bumps out of our hot path is not premature.
jandrewrogers 4y ago
Performance is not a primary objective for most software. For the subset where it is, most performance is architectural; if you don't design for performance from the outset then you'll never be able to add it later. People that have been in the performance business a long time, the kind of people you want if performance matters, can estimate the performance of code without running it to a degree of accuracy that is surprising to people with no performance engineering experience. Not understanding the relationship between code and performance is not the same as no one being able to understand the relationship between code and performance. It is a specialized discipline but people in it don't need to measure code for macro-optimization purposes. You still need to measure some things for micro-optimization purposes, but even there you'll find savants that really don't need to. Naturally, there is an element of many developers overestimating their ability to estimate code performance. That is not universal though. I've worked with developers that could consistently and precisely describe the performance characteristics of code on real hardware without running it. A lot of computer science is premised on this being possible. Acting like this is unknowable is doing a disservice to computer science as a discipline. If you understand how code interacts with hardware then performance is deterministic and obvious. There are degrees, of course, but some developers have a deeply intuitive understanding of these relationships.

Archelaos 4y ago

But even that has to be taken with a grain of salt. There are kinds of critical code that are hard to identify. Think of the infamous O(n^2) algorithms which are not identified unless you measure high values of n. Or not well coordinated threads that slow down a programm only on specific occasions.

junon 4y ago
Yes, but conversely, there are cases where O(1), O(N) and O(N^2) are all perceptually the same in all cases of a particular program. There's a bit of an art to determining what is critical and non-critical.

zionic 4y ago

>A good programmer will not be lulled into complacency by such reasoning And that's the crux of it. Donald neglected to understand that most programmers will takeaway "optimization is bad" and all the subtleties of his point will be lost. Then we get things like electron (ducks for cover)

ummonk 4y ago
Donald was also writing at a time when all languages were close to the metal and optimization meant using various tricks (or writing critical portions in assembly) to improve performance.
- FpUser 4y ago
  >"when all languages were close to the metal" That writing was 1974, Lisp had already existed.
  - ncmncm 4y ago
    And even caches. Though we called it "core", back then. Main memory was disk, tape, or drum, and cache misses caused page faults, if you were fortunate, or you had to roll in overlays yourself. Nowadays RAM is as inaccessible as disk was then, and you swap 64-byte pages, sometimes with network negotiations with remote (NUMA) cores, all in hardware.
Ygg2 4y ago
> Then we get things like electron We get electron because it's a batteries included (and remote and TV) cross platform GUI. And has a huge talent pool, and acceptable performance for most users.

Someone 4y ago

I agree. This is immature optimization. Back to ”Premature optimization is the root of all evil”: I think that’s a bad statement. The only thing that says something there is all, and it is incorrect. “Premature (noun) is the root of evil” is true for about every noun you can out there. “Premature design is the root of evil”, “Premature programming is the root of evil”, “Premature debugging is the root of evil”, etc. Adding all implies there aren’t other things that are (in this context) roots of evil. I don’t think that’s true. As an example, one can spend excessive amounts of effort thinking about, or worrying about the ‘beauty’ of source code.

osigurdson 4y ago
I suspect when Knuth first came up with this phrase, he didn't expect it to be taken as gospel.

hyperpallium2 4y ago

He's making a more general statement, with "root of all evil", that improving some aspect of something without understanding its effects on the whole outcome, is literally the root cause of evil in the world, in general. Winning the battle but losing the war. Not seeing the forest for the trees. Getting lost in the weeds. Unenlightened self-interest. Not hyperbole, but a particular instance of a general concept. But on code optimization, k deeply nested loops are not a bad guide to O(n^k), and a candidate for optimization. That said, I once cached something that obviously needed to be cached - so obvious in fact that a deeper level in the system already cached it.

worik 4y ago

The original biblical quote it riffs off is often, mostly, misquoted as: Money is the root of evil. It actually is (give or take for translation) "For the love of money is a root of all kinds of evil." Timothy 6:10 The love... A root... All kinds...