7 ms·

There are very few phrases in all of history that have done more damage to the project of software development than: "Premature optimization is the root of all

• devnullbrain 7mo ago
  > and the missing context is essential. Oh yes, I'd recommend everyone who uses the phrase reads the rest of the paper to see the kinds of optimisations that Knuth considers justified. For example, optimising memory accesses in quicksort.
  • anymouse123456 7mo ago
    Exactly! I wish Knuth would come out and publicly chastise the many decades of abuse this quote has enabled.
    • trey-jones 7mo ago
      To be fair, I think human nature is probably a bigger culprit here than the quote. Yes, it was one of the first things told to me as a new programmer. No, I don't think it influenced very heavily how I approach my work. It's just another small (probably reasonable) voice in the back of my head.
  • kalaksi 7mo ago
    This shows how hard it is to create a generalized and simple rule regarding programming. Context is everything and a lot is relative and subjective. Tips like "don't try to write smart code" are often repeated but useless (not to mention that "smart" here means over-engineered or overly complex, not smart).
    • pydry 7mo ago
      I dunno, Ive seen people try to violate "dont prematurely optimize" probably a thousand times (no exaggeration) and never ONCE seen this happen: 1. Somebody verifies with the users that speed is actually one of the most burning problems. 2. They profile the code and discover a bottleneck. 3. Somebody says "no, but we shouldnt fix that, that's premature optimization!" Ive heard all sorts of people like OP moan that "this is why pieces of shit like slack are bloated and slow" (it isnt) when advocating skipping steps 1 and 2 though. I dont think they misunderstand the rule, either, they just dont agree with it. Did pike really have to specify explicitly that you have to identify that a problem is a problem before solving it?
      • devnullbrain 7mo ago
        >1. Somebody verifies with the users that speed is actually one of the most burning problems. Sometimes this is too late. C++98 introduce `std::set` and `std::map`. The public interface means that they are effectively constrained to being red-black trees, with poor cache locality and suboptimal lookup. It took until C++11 for `std::unordered_map` and `std::unordered_set`, which brought with them the adage that you should probably use them unless you know you want ordering. Now since C++23 we finally have `std::flat_set` and `std::flat_map`, with contiguous memory layouts. 25 years to half-solve an optimisation problem and naive developers will still be using the wrong thing. As soon as the interface made contact with the public, the opportunity to follow Rob Pike's Rule 5 was lost. If you create something where you're expected to uphold a certain behaviour, you need to consider if the performance of data structures could be a functional constraint. At this point, the rule becomes cyclical and nonsensical: it's not premature if it's the right time to do it. It's not optimisation if it's functional.
  • lynndotpy 7mo ago
    Yep. If one is implementing quicksort for a library where it will be used and relied on, I'd sure hope they're optimizing it as much as they can.
• frereubu 7mo ago
  Totally agree. Out of this context, the word "premature" can mean too many things.
• aljgz 7mo ago
  In all honesty, this is one of the less abused quotes, and I have seen more benefit from it than harm. Like you, I've seen people produce a lot of slow code, but it's mostly been from people who would have a really hard time writing faster code that's less wrong. I hate slow software, but I'd pick it anytime over bogus software. Also, generally, it's easier to fix performance problems than incorrect behavior, especially so when the error has created data that's stored somewhere we might not have access to. But even more so, when the harm has reached the real world.
  • anymouse123456 7mo ago
    I don't believe there is any tension at all between fast and simple software. We can and should have both. This is a fraud, made up by midwits to justify their leaning towers of abstraction.
    • embedding-shape 7mo ago
      User-facing, sure, nothing stopping us from doing "simple and fast" software. But when it comes to the code, design and architecture, "simple" is often at odds with "fast", and also "secure". Once you need something to be fast and secure, it often leads to a less simple design, because now you care about more things, it's kind of hard to avoid.
      • ndriscoll 7mo ago
        IME doing application servers and firmware my whole career, simple and fast are usually the same thing, and "simple secure" is usually better security posture than "complex secure".
        • embedding-shape 7mo ago
          Interesting, never done firmware, but plenty of backends and frontends. Besides the whole "do less and things get faster", I can't think of a single case where "simple" and "fast" is the same thing. And I'd agree that "simple secure" is better than "complex secure" but you're kind of side-stepping what I said, what about "not secure at all", wouldn't that lead to simpler code? Usually does for me, especially if you have to pile it on top of something that is already not so secure, but even when taking it into account when designing from ground up.
• bko 7mo ago
  > Multiple generations of programmers have now been raised to believe that brutally inefficient, bloated, and slow software is just fine. There is no limit to the amount of boilerplate and indirection a computer can be forced to execute. There is no ceiling to the crystalline abstractions emerging from these geniuses. There is no amount of time too long for a JVM to spend starting. I think that's due to people doing premature optimization! If people took the quote to heart, they would be less inclined to increasing the amount of boilerplate and indirection.
  • ummonk 7mo ago
    The boilerplate and indirection isn't done for performance
• YesThatTom2 7mo ago
  I hear you, friend! While you were seeing those problems with Java at Google, I saw seeing it with Python. So many levels of indirection. Holy cow! So many unneeded superclasses and mixins! You can’t reason about code if the indirection is deeper than the human mind can grasp. There was also a belief that list comprehensions were magically better somehow and would expand to 10-line monstrosities of unreadable code when a nested for loop would have been more readable and just as fast but because list comprehensions were fetishized nobody would stop at their natural readability limits. The result was like reading the run-on sentence you just suffered through.
• twoodfin 7mo ago
  Ignoring optimization opportunities until you see the profile only works when you actually profile! Profiling never achieved its place in most developers’ core loop the way that compiling, linting, or unit testing did. How many real CI/CD pipelines spit out flame graphs alongside test results?
  • pydry 7mo ago
    I usually defer this until a PM does the research to highlight that speed is a burning issue. I find 98% of the time that users are clamoring to get something implemented or fixed which isnt speed related so I work on that instead. When I do drill down what I tend to find in the flame graphs is that your scope for making performance improvements a user will actually notice is bottlenecked primarily by I/O not by code efficiency. Meanwhile my less experienced coworkers will spot a nested loop that will never take more than a couple of milliseconds and demand it be "optimised".
    • lokar 7mo ago
      Even at Google, the tendency is (or was when I was there), to only profile things that we know are consuming a lot of resources (or for sure will), or are hurting overall latency. Also the rule (quote?) says "speed hack", I don't think he is saying ignore runtime complexity totally, just don't go crazy with really complex stuff until you are sure you need it.
      • Jensson 7mo ago
        That depends on which part of Google. I worked in the hot path of the search queries and there speed was extremely important for everything, they want to do so much there every single query and latency isn't allowed to go up.
    • IshKebab 7mo ago
      The problem with ignoring performance is that you'll always end up with slow software that is awful to use but ticks all the feature boxes. As soon as someone comes along that is fast and nice people will switch to that. People don't ask for software to be fast and usable because it obviously should be. Why would they ask? They might complain when it's unusably slow. But that doesn't mean they don't want it to be fast.
• sph 7mo ago
  Another one from my personal experience: apply DRY principles (don't repeat yourself) the third time you need something. Or in other words: you're allowed to copy-and-paste the same piece of code in two different places. Far too often we generalise a piece of logic that we need in one or two places, making things more complicated for ourselves whenever they inevitably start to differ. And chances are very slim we will actually need it more than twice. Premature generalisation is the most common mistake that separates a junior developer from an experienced one.
  • busfahrer 7mo ago
    Agreed, I think even Carmack advocates this rule
  • cjs_ac 7mo ago
    DRY follows WET (Write Everything Twice).
  • colechristensen 7mo ago
    Ehh, people who are really excited about DRY write unreadable convoluted code, where the bulk of the code is abstractions invented to avoid rewriting a small amount of code and unless you're very familiar with the codebase reasoning about what it actually does is a mystery because related pieces of functionality are very far away from each other.
    • trey-jones 7mo ago
      DRY is not to avoid writing code (of any amount). DRY is a maintainability feature. "Unless you're very familiar with the code" you probably won't remember that you have to make this change in two places instead of one. DRY makes life easier for future you, and anyone else unfortunate to encounter (y)our mess.
      • bluGill 7mo ago
        You are confusing DRY done as intended vs what DRY looks like in the real world to many people.
• dwb 7mo ago
  Totally agree. I’ve see that quote used to justify wilfully ignoring basic performance techniques. Then people are surprised when the app is creaking exactly due to the lack of care taken earlier. I would tend to argue the other way most of the time: a little performance consideration goes a long way! Maybe I’ve had an unrepresentative career, but I’ve never worked anywhere where there’s much time to fiddle with performance optimisations, let alone those that make the code/system significantly harder to understand. I expect that’s true of most people working in mainstream tech companies of the last twenty years or so. And so that quote is basically never applicable.
• pjc50 7mo ago
  Slow code is more of a project management problem. Features are important and visible on the roadmap. Performance usually isn't until it hits "unacceptable", which may take a while to feed back. That's all it is. (AI will probably make this worse as well, having a bloat tendency all of its own)
• lowmagnet 7mo ago
  I always point out the operational word is "premature".
• dominotw 7mo ago
  > I have lived the absolute nightmares that evolve from the willful misunderstanding of this quote. how do you know which code was written using this quote in mind.
  • BoneShard 7mo ago
    He doesn't know, but that quote makes for a cool talking point. Software is slow or bloated because of budget, deadlines, and skill levels - not because of a quote.
• globular-toast 7mo ago
  So you're saying people have misunderstood "premature optimisation is the root of all evil" as "optimisation is the root of all evil"? I don't think you can blame this phrase if people are going to drop an entire word out of an eight word sentence. The very first word, no less.
• bluGill 7mo ago
  Don't confuse premature pessimization for the warnings against premature optimization. I can write bubble sort, it is simple and I have confidence it will work. I wrote quicksort for class once - I turned in something that mostly worked but there were bugs I couldn't fix in time (but I could if I spent more time - I think...) However writing bubble sort is wrong because any good language has a sort in the standard library (likely timsort or something else than quicksort in the real world)
• taneq 7mo ago
  > I have lived the absolute nightmares that evolve from the willful misunderstanding of this quote. Then the quote wasn’t the problem. The wilful misunderstanding was the problem.
• koliber 7mo ago
  Picking the starting point is very important. "optimization" is the process of going from that starting point to a more performant point. If you don't know enough to pick good starting points you probably won't know enough to optimize well. So don't optimize prematurely. If you are experienced enough to pick good starting points, still don't optimize prematurely. If you see a bad starting point picked by someone else, by all means, point it out if it will be problematic now or in the foreseeable future, because that's a bug.
  • zephen 7mo ago
    > If you see a bad starting point picked by someone else, by all means, point it out if it will be problematic now or in the foreseeable future, because that's a bug. Can't disagree at all, but many people push back in the name of XP.
• JTbane 7mo ago
  Anyone else feel like bloat is usually not an algorithmic problem, but rather a library or environment issue most of the time?
• wavemode 7mo ago
  I don't think the quote itself is responsible for any of that. It's true that premature optimization (that is, optimization before you've measured the software and determined whether the optimization is going to make any real-world difference) is bad. The reality, though, is that most programmers aren't grappling with whether their optimizations are premature, they're grappling with whether to optimize at all. At most companies, once the code works, it ships. There's little, if any, time given for an extra "optimization" pass. It's only after customers start complaining about performance (or higher-ups start complaining about compute costs) that programmers are given any time to go through and optimize things. By which point refactoring the code is now much harder than it wouldn've been originally.
• Megranium 7mo ago
  Huh, I've always understood that quote very differently, with emphasis on "premature" ... not as in, "don't optimize" but more as in "don't optimize before you've understood the problem" ... or, as a CS professor of mine said "Make it work first, THEN make it work fast" ...
  • DarkCrusader2 7mo ago
    well you see, in corporate (atleast in big tech), this is usually used as a justification to merge inefficient code (we will optimize it later). That later never comes, either the developers/management moves on or the work item never gets prioritized. That is until the bad software either causes outages or customer churn. Then it is fixed and shown as high impact in your next promo packet.
  • lokar 7mo ago
    And if you know in advance that a function will be in the critical path, and it needs to perform some operation on N items, and N will be large, it’s not premature to consider the speed of that loop.
    • lokar 7mo ago
      Another thought: many (most?) of these "rules" were before widespread distributed computing. I don't think Knuth had in mind a loop that is reading from a database at 100ms each time. I've seen people write some really head shaking code that makes remote calls in a loop that don't actually depend on each other. I wonder to what extend they are thinking "don't bother with optimization / speed for now"
      • rob74 7mo ago
        If you really have a loop that is reading from a database at 100ms each time, that's not because of not having optimized it prematurely, that's just stupid.
        • lokar 7mo ago
• divan 7mo ago
  > generations of programmers have now been raised to believe that brutally inefficient, bloated, and slow software is just fine. I believe people don't think about Knuth when they choose to write app in Electron. Some other forces might be at play here.
• imjonse 7mo ago
  I was a bit worried you are paraphrasing Rob Pike, but no, he actually agrees with that Knuth quote. I am almost certain that people building bloated software are not willfully misunderstanding this quote; it's likely they never heard about it. Let's not ignore the relevance of this half a century old advice just because many programmers do not care about efficiency or do not understand how computers work. Premature optimization is exactly that, the fact that is premature makes it wrong, regardless if it's about GOTO statements in the 70s or a some modern equivalent where in the name of craft or fun people make their apps a lot more complex than they should be. I wouldn't be surprised if some of the brutally inefficient code you mention was so because people optimized prematurely for web-scale and their app never ever needed those abstractions and extra components. The advice applies both to hackers doing micro-optimizations and architecture astronauts dreaming too big IMHO.
  • IshKebab 7mo ago
    No I've definitely heard plenty of people use this as some kind of inarguable excuse to not care about performance. Especially if they're writing something in Python that should really be not super slow. "It's fine! Premature optimisation and all that. We'll optimise it later." And then of course later is too late; you can't optimise most Python.
• lynndotpy 7mo ago
  I think the bigger problem is that "Premature optimization is the root of all evil" is a statement made by software engineers to feel more comfortable in their shortcomings. That's not to bemoan the engineer with shortcomings. Even the most experienced and educated engineer might find themself outside their comfort zone, implementing code without the ability to anticipate the performance characteristics under the hood. A mental model of computation can only go so far. Articulated more succinctly, one might say "Use the profiler, and use it often."
• trgn 7mo ago
  > Multiple generations of programmers have now been raised to believe that brutally inefficient, bloated, and slow software is just fine 100%
• trgn 7mo ago
  A lot of developers get enamored by fetishes. Just one example, because it's one i always struggle to vanquish in any of my teams. Devs are obsessed with introducing functional-style constructs everywhere, just for the sake of it. FP is great for some classes of software, but baseline crufty for anything that requires responsiveness (front-ends basically), let alone anything at real interactive speeds (games, geo-software, ...) The "premature optimization" quote is then always used as a way to ignore that entire code paths will be spamming the heap with hundreds of thousands of temporary junk, useless lexical scopes, and so forth. Writing it lean the first time is never considered, because of adherence to these fetishes (mutability is bad, oo is bad, loops lead to off-by-one errors, ...). It's absolutely exhausting to have these conversations, it's always starting from the ground up and these quotes like "premature optimization is the root of all evil" are only used as invocations to ward of criticism.
• 01100011 7mo ago
  This is the sort of pontifical statement that old guys like me tend to make which is strictly wrong but also contains a lot of wisdom. Yes, software is bloated, full of useless abstractions and bad design. You kids(well, anyone programming post 1980, so myself included) should be ashamed. Also let's not forget that those abstractions helped us solve problems and our friends in silicon valley(ok that no longer makes sense but imagine if SillyValley still just made HW) covered our mistakes. But yeah, we write crap a lot of the time. But as other folks have said, it doesn't mean "don't optimize." I've always used my own version of the phrase, which is: "Don't be stupid." As in, don't do dumb, expensive things unless you need to for a prototype. Don't start with a design that is far from optimal and slow. After profiling, fix the slow things. I'm pretty sure that's what most folks do on some level.
• whatever1 7mo ago
  At least before the LLM world you would have to trade money (aka more compute) for time to market. What is the point of spending a single second optimizing a query when your database has 10 users? Of course today this has changed. You can have multiple agents working on micro optimizing everything and have the pie and eat it too.
• pphysch 7mo ago
  It has less to do with a quote and more to do with CS education (and the market) rewarding minimal functionality over performance, security, fault-tolerance, etc. The average university CS student in USA (and India I presume) is taught to "hack it" at any cost, and we see the results.
• deleted 7mo ago
  [deleted]
• dblohm7 7mo ago
  I too learned this the hard way, via a supposedly concurrent priority queue that did quadratic-time work while holding a lock over the entire thing. I was told that "premature optimization is the root of all evil." Sorry, folks, but that's just an excuse to make dumb choices. Premature _micro_optimization is the root of all evil. EDIT: It was great training for when I started working on browser performance, though!
  • dblohm7 7mo ago
    And if I may add a corollary: Measurement doesn't need to be held off until the end of the project! Start doing it as soon as you can!
• jayd16 7mo ago
  This discussion kind of irks me. I just read these posts as: "The quote saying A is bad. Actually it said A all along!" It's just complaining about others making a different value judgement for what is a worthwhile optimization. Hiding behind the 'true meaning of the quote' is pointless.
• andoando 7mo ago
  As someone currently writing 16-18 tables all with common definition, and crud, Id like some abstraction
• didgetmaster 7mo ago
  I agree. Faster hardware or horizontal scaling on distributed cloud environments can mask the problem; but it certainly doesn't solve the problem of bloated, inefficient software. While it might not be necessary to spend hours fine-tuning every function; code optimization should be the mindset of every programmer no matter what they are coding. How many fewer data centers would we need if all that software running in them was more efficient? https://didgets.substack.com/p/finding-and-fixing-a-billion-bug https://didgets.substack.com/p/finding-and-fixing-a-billion-...
• rixed 7mo ago
  I wish we lived in a world where quotes could be that powerful. But I'm afraid in reality this quote, like any other, is just used as a justification after the fact. Actually, I do not believe devs are to blame, or that CS education is to blame; I believe that's an unfortunate law of society that complexity piles up faster than we can manage it. Of course the economic system rewards shiping today at the expense of tomorrow's maintenance, and also rewards splitting systems in seemingly independent subsystems that are simpler in isolation but results in a more complex machinery (cloud, microservices...) I'm even wondering if it's not a more fundamental law than that, because adding complexity is always simpler than removing it, right? Kind of a second law of termodynamic for code.
• Someone 7mo ago
  > From his 1974 paper, "Structured Programming with go to Statements": > He was talking about using GOTO statements in C. I don’t think he was talking about C. That paper is from December 1974, and (early) C is from 1972, and “The UNIX Time-Sharing System” (https://dsf.berkeley.edu/cs262/unix.pdf https://dsf.berkeley.edu/cs262/unix.pdf) is from July 1974, so time wise, he could have known C, but AFAICT that paper doesn’t mention C, and the examples are PL/I or (what to me looks like) pseudocode, using ‘:=’ for assignment, ‘if…fi’ and ‘while…repeat’ for block, ‘go to’ and not C’s ‘goto’, etc.
  • zahlman 7mo ago
    Yes, just like in Dijkstra's earlier (1968) "Go To Statement Considered Harmful". The syntax is not C and "go to" is two words, and of course that's definitely too early.
  • anymouse123456 7mo ago
    I kind of love this. Thanks for the correction!