9 ms·

The Fallacy of Premature Optimization (2009)

54 points by kretaceous 4y ago

osigurdson 4y ago
Unexamined phrase based development is the true root of all evil.
- jcelerier 4y ago
  "Considered harmful" considered harmful
  - beckingz 4y ago
    ""Considered harmful" considered harmful" considered harmful. There are only two hard problems in computer science: "cache invalidation, naming things, and humorous recursion.
  - chillfox 4y ago
    I really hate the "X Considered harmful" type of articles, like by who? Inevitably they try to fake a larger consensus where one does not exist. Just be hones and say "I think X is a bad idea"...
    - osigurdson 4y ago
      Exactly. Use simple language. State what you like / dislike about something and provide a compelling argument. Don't try to add false legitimacy with a "considered harmful" title. If your argument has a broad consensus, then state exactly which groups have come to that conclusion.
- pif 4y ago
  And dogmas, too!
  - trashtester 4y ago
    Your dogmas are the heuristics you take for granted that I know to be bad/false, and vice versa. Dogma is the simplifications we teach to children (and students and junior devs) so they don't have to contemplate the full complexity of reality. The problem is when we start to attach our identity to these dogma, and hold them so precious that we will never give them up. Without our dogma/heuristics we get lost. But we need to know how to give up on the ones that are no longer useful.
    - osigurdson 4y ago
      I think you are conflating "dogma" with "mental model". The accepted meaning of "dogma" is a strong belief that adherents are not willing to discuss rationally.
      - gopher_space 4y ago
        He's using the word as a term of art.
      - trashtester 4y ago
        "Dogma" is the word we use to decribe the kind of beliefs other people have that they are not willing to discuss rationally. Most of us will have a hard time recognizing our own dogma. My claim is that we all have things we believe dogmatically. They for the axioms of our mental models. Take away the dogma, and our entire mental framework risks getting shattered. If we completely fail to understand this, though, we are at risk of constructing rationalistic (as opposed to rational) frameworks on top, in believe in them absolutely. This can lead to fanatical movements such as Islamic suicide bombers, "Objetivist" capitalists, Extinctin Rebellion or Conquistador Missionaries. And also all sorts of cargo cults in software development.
        osigurdson 4y ago
        >> My claim is that we all have things we believe dogmatically. They for the axioms of our mental models. I agree but think of it as a scalar. Some mental models are assigned a "conviction" of 1.0 - that could be considered dogma. Some (like the expectation of what tomorrow's weather might be like) may have a "conviction" of 0.3.
RunSet 4y ago
Hint: If your software ships Chrome its optimization is overdue, not premature. Looking at you, Electron apps.
- TeMPOraL 4y ago
  Yeah, wish people would apply that to their process. Perhaps going straight for Electron is a premature optimization of the development process.
kasey_junk 4y ago
“Systems that are designed without any thought of performance rarely perform well, even with an extensive optimization phase at the end of the software development cycle.” I’d go further, if performance is not part of your initial requirements you’ll never get it. Performant systems come from architecture and data modeling. Heck in the modern era data load patterns Trump algorithmic efficiency even. Those things are very challenging to back into a codebase.
ngrost24 4y ago
Not sure how I feel about this article... there are some valid points, but also some half-truths, where the answer is more "it depends" than yes or no. The feeling I get is that the article tries to make a long list of all possible causes, which dilutes the main reasons why premature optimisation or even optimisation is skipped. It also doesn't try to see the issue from the other side and inform the reader when optimisation is premature and doesn't need to be considered, which makes its argument very one-sided. One additional point that I think might be missing from this list imo, is the shifting functionality requirements given to the developers which make it less certain that a specific piece of code will be the foundation on which you will build the rest of the logic or whether it will be a leaf-level logic that will be used very infrequently but this comes with other caveats regarding refactoring, etc.
323 4y ago
To quote Andrei Alexandrescu, "Premature optimization is bad, but premature pessimization is also bad".
Gunax 4y ago
The thrust is that Hoare's statement has been misapplied (I agree!) but even moreso: just because someone said it, and someone famous repeats it, does not mean it's true. The statement is really a bit of a tautology: what is 'pre-mature' afterall? Well, it's any optimization that is not going to bear fruit for the user. So the statement might as well be 'optimizations which do not improve the user experience do not improve the user experience'. I see these sort of statements a lot. 'dont add too much salt', or 'dont drive too fast'. They dont really say much other than 'there is some max point which should not be exceeded'. I guess my point is that it doesn't really guide us. Of course any 'pre-mature' optimization is not useful. The difficulty is knowing whether it's pre-mature, which can only gained through experience. I think the reality is that optimizing code is not-fun. Adding features is fun. Writing tests is not-fun. If given the chance, we will find excuses to avoid the not-fun parts of software.
- userbinator 4y ago
  I think the reality is that optimizing code is not-fun. Adding features is fun. Writing tests is not-fun. If given the chance, we will find excuses to avoid the not-fun parts of software. To what is unfortunately a minority, it's the exact opposite. I enjoy optimising existing code more than adding new code.
- jasmer 4y ago
  You'll know it when you see it. My gosh man the things I tried to do as a young Eng. myself - some of the tedious things I did to avoid copying strings or this or that! It's hard to see how such things add to 'complexity' in a way that slows down the project. 'Keep it Idiomatic' is a great way to keep things moving and as things become problematic, they can be tweaked. Obviously in some cases that's not going to work.
rossdavidh 4y ago
I have never, in 18 years of professional programming, heard "premature optimization..." used to mean that "you should never optimize your code!" Not saying it never happens, but I have never heard it once used that way. I do occasionally hear it used to mean "don't spend the time to optimize until you have measured whether this is your bottleneck and it will actually matter", or "get it working first so that you know this is actually what you even want, otherwise you will end up optimizing things that get cut soon after". Both of which are valid.
- trashtester 4y ago
  I've personally, in my 25 years of professional programming, heard it many times to mean "I don't want to consider performance at this stage of development, I want to move ALL optimization to when the code is done." Typically after I've made comments on their design very early in the development process about the code being doomed to be very slow, in a manner that cannot be solved by optimizing small parts of the code later (so will require a rewrite). And I'm not talking about the small wins, that make things 10-50% faster. I'm talking about design mistakes that slow down the code by several orders of magnitude. (Big-O stuff), and that is represented at a point in the design that is so fundamental it's hard to fix without scrapping everything.
- JKCalhoun 4y ago
  An example might be images used as thumbnails in the UI. If they are fetched over the network, you might as well plan to have a local image cache. No need to wait on that one - and I would not call that premature optimization. Perhaps others would though (ha ha, and perhaps they’re right if there is already a cache in some other hidden part of the pipeline - yes, I am undercutting my own argument).
  - peteradio 4y ago
    > if there is already a cache in some other hidden part of the pipeline Still counts as a win, you can IME take out a cache mechanism easily. If somebody wants to ding you for writing excess code I don't know what to tell you, they are probably a-holes.
omginternets 4y ago
Rich Hickey has a succinct quote that reveals the abuse that Hoare's "premature optimization" quote has undergone: the cheapest place to fix bugs is in design. And if we're going to proceed by quotation, another one to consider is Linus Torvalds': Bad programmers worry about the code. Good programmers worry about data structures and their relationships. IMHO, a big thing for junior programmers to unlearn is that one should begin by putting a sloppy version of the program in production, and incrementally improve it thereafter. A little bit of forethought and a bit of attention paid to big-O will do three things: (1) make incremental improvement easier (2) limit the amount of incremental improvement needed, and (3) avoid painting you into a corner wherein significant refactors are needed. As it turns out, thinking ahead of time is not antithetical to shipping code. Quite the contrary.
- jasmer 4y ago
  I beg to differ. What has to be 'unlearned' is that Engineers think they have a clear vision of what they need to do ... but in reality they don't. This largely has to do with 'unknown unknowns', particularly in requirements. It's actually a much harder concept to learn/unlearn - because we are trained to design towards specs, towards a kind of perfection, to solve problems in which the conditions are contrived. Almost nothing in the academic world prepares people for having to build something whereupon the objectives are a bit fuzzy - especially when said objectives are not presented as fuzzy. It almost requires the 'experience of failure' to grasp that most things that can be incrementally built - should be. The process of building something, is actually a process of 'discovery'. I think that the only time 'prepping far ahead' becomes useful, is when Engineers are building on very foundational, learned knowledge derived from a relevant situation, in which case they are actually acting in an iterative fashion, leveraging knowledge from the previous 'situation' - but even then, I would not consider that for optimization, rather, just keeping a lid on arbitrary complexity. And finally, of course some things are reasonable. You probably are not going to build a high performance codec in Python.
  - trashtester 4y ago
    Agree with almost everything above, except the first line. In military strategy there is the quote "Plans Are Worthless, But Planning Is Everything" [1]. I think the same goes for software design. To believe that one can do a complete design of some piece of software, and then implement it precisely as planned, is folly, just as for military plans. Still, it is imperative to do some deep thinking about the purpose of the software as one starts coding, especially about things like the purpose of the software (and what is NOT the purpose), design and design philosophy and expected challenges (including performance challenges) including ideas about how to find solutions to those challenges. Also, after starting to code, it's important to revisit these aspects. Is the purpose changing? If it is, is that good or bad? How do we define the new purpose? Are we making changes to the design? Why? Do we need to refine the design concepts? And so on. Just like for military strategy, this is an art more than a science. We have strong limitations dictated by what is possible, yet it is essential to have an overall idea of what direction we want to move in. Otherwise we, more likely than not, end up with a useless patchwork. [1] https://quoteinvestigator.com/2017/11/18/planning/ https://quoteinvestigator.com/2017/11/18/planning/
deleted 4y ago
[deleted]
lordnacho 4y ago
A lot of coding decisions come down to that elusive idea, judgement. Think about what the pros and cons are, what the scope is, budget, and... decide what to do. I've never come across one of these articles that doesn't boil down to "think about it". That's not to trivialize it, because of course it can take years to hone your development judgement powers, but essentially such articles are only useful so far as they tend to contain a long-form list of commonly encountered thinking points. More specific experience gives you more detailed items on your list. Level 0 of the performance considerations (relevant to every vertical) is maybe whether you can just throw more hardware at it. In my little vertical (finance) you might think about what data structure to use based on what instrument type you're building a system for.
pkilgore 4y ago
"Dogma is the root of more evil"
begueradj 4y ago
Is that really what all premature optimization is about ?
gwbas1c 4y ago
Here's the problem: If you pick a poor framework, pattern, or abstraction at the beginning, and leave optimization to the end... You end up needing to do a significant refactor or rewrite. Translation: Don't suck the entire DB into RAM to read a single value.
- Koshkin 4y ago
  Translation of translation: leave it for the OS to do it for you :)
gaze 4y ago
Worse is better vs plan carefully is this balance that shows up in every creative field. It’s in writing, in physics, art, everything. Do you try and think carefully up front about what you want to and engineer carefully against what you imagine the requirements to be, or do you hack and slash your way to your goal? Not only is there no right answer, but the right answer changes day by day, hour by hour. It’s the central meta-decision. Making this decision with good judgement is one of the key skills of a good engineer. Someone who applies “worse is better” regardless of the context is a bad engineer. Someone who never finishes anything because they’re overthinking and overabstracting is likewise a bad engineer.
celeritascelery 4y ago
> Observation #6: Software engineers have been led to believe that their time is more valuable than CPU time; therefore, wasting CPU cycles in order to reduce development time is always a win. They've forgotten, however, that the application users' time is more valuable than their time. This is the key thing. I can hardly think of single application where my number one feature request isn’t “make it faster”. Rarely am I interested in a “fresh new look” or “more buttons”. If you can make some task take 5 seconds instead of 10, that is a win for everyone.
- pizza234 4y ago
  YMMV. I, for example, work in a field where for customers, as long as performance is good enough, features-features-features is the number one priority. Visual Studio Code is actually a good example of "performant enough" software; it's famous (appealing) for its extensibility, but certainly not performance. Then there are cases like Slack or GNOME 3, which were adopted even with lackluster performance. Go figure :|
  - TeMPOraL 4y ago
    > I, for example, work in a field where for customers, as long as performance is good enough, features-features-features is the number one priority. There are fields like that. Then there are fields that seem to be like that, but where it's just the person making the purchase decision that cares about "features-features-featues", and actual users don't use most of them and would instead prefer faster software with sane UX. I've definitely seen more of the latter than the former in my life. > Then there are cases like Slack or GNOME 3, which were adopted even with lackluster performance. Go figure :| Nothing to figure out here, it's about who is making the choice, and what choices are available on the market. Slack case is the very common situation of the choice being made by few people (not necessarily best suited for making that choice) for the whole organization / community, and heavily influenced by all the marketing spend and dirty tactics Slack the company did. GNOME 3 is the case of a supplier-driven choice: i.e. some distros defaulted to it for whatever reasons, and people mostly had to accept it, because WM is one but many qualities you care about in a distro, and alone not enough to make you choose a different one. Both types are common situations on the market, and not at all limited to software. To again name them, in short: 1. People making the choice are not the end-users of the product/service. 2. Choice is made by the supplier, and the market doesn't provide an equivalent alternative that made a different choice.
fendy3002 4y ago
People are treating optimization as a zero or one thing. While in fact there are many middle grounds. If we're taking Pareto principle into account, I can say that we can do 20% of optimization to get 80% of the benefit. The more experienced you are, the easier that first 20% is.
Nursie 4y ago
This whole article is a straw man AFAICT. Premature optimisation is not an excuse to avoid thinking about runtime characteristics either at design or implementation time. Premature optimisation is the junior engineer using some cargo-cultish ideas to attempt to shave a couple of instructions off a loop which a) is unlikely to be any sort of bottlneck and b) is going to be picked up by the compiler anyway if it's that simple. It's spending days of effort making some piece of code faster when in practice that piece of code is neither executed often nor on any critical path. "The Fallacy of Premature Optimisation" seems to me to be an article which takes the worst behaviours of people who don't believe in optimisation at all, and uses them to dismiss the entire idea that effort could be misapplied in dead-end microoptimisations that don't achieve anything.
- trashtester 4y ago
  Maybe you've been more lucky than me, but I've seen plenty of such "junior devs" in positions of influence, with titles such as "senior" or "principal" dev, "architect" or "engineering manager". In many places, titles like that accrue automatically as people get older, especially if they play the political game reasonably well. Some of them will then happily do what you correctly label "Premature optimization" in the microcode, but proceed to make big mistakes in the overall design that leads to several orders of magnitude slowdowns in the general design. I believe the problem is in the training. As junior devs, they may have been scolded for premature optimizations of microcode, but worked within a well thought-out design at the macro level. Then they advance in ranks, and have to do the design part as well, but they never learned to think about the performance at that level, something that benefits a lot from some contemplation up front.
29athrowaway 4y ago
To me, premature optimization is trying to optimize a solution before you understand how it works.
didgetmaster 4y ago
Even though computing resources have grown by leaps and bounds over the past few decades; it seems that the amount of data has grown by even more. I have found that it is much easier to generate twice as much data needed for processing than it is to get the processing of it to run twice as fast. When you multiply by really big numbers, the problem becomes very apparent. A wasted millisecond in a function doesn't seem like much until you call it a million times.
agentultra 4y ago
I always make performance considerations part of my specifications when they matter. Resources are not infinite! Often performances are part of the requirements even though they are implied. Our requirement for a traffic control system might be primarily concerned with the safety of motorists and pedestrians crossing an intersection. However it's generally implied that this system should eventually allow some cars through and some pedestrians through. And that nobody is left waiting too long! Such a system wouldn't be terribly useful if pedestrians never get a chance to cross because the light never changes. It's not premature optimization to design your system with resource constraints in mind. It's smart engineering! A user shouldn't have input lag to scroll a document. The game engine doesn't need to render an infinite number of entities. An HTTP resource shouldn't be returning every record in the database. If you keep these constraints in mind in the design phase you generally end up with a well performing application. Ignoring them is what I've heard called, "premature pessimization," and is a popular source of performance problems in mature applications.
twawaaay 4y ago
I think biggest problem about "premature optimisation" is the problem that defining "premature" has been left to the reader and everybody has their own definition. Then they will spar online completely needlessly because they are comparing apples to oranges. The important thing to remember is that the earlier in development something is fixed, the cheaper it gets. The longer a problem persists throughout the process, the more expensive it will be to fix. And "more" here means "exponentially more". Because at the time of design or discussing with the client I may be able to fix it in a second by just choosing a different option. Once it gets to production it might be either impossible or costs millions and months of development. The job of the person who designs it is to identify which decisions will be hard to undo later if they are found to be wrong and focus on making sure these are done correctly.
zugi 4y ago
> The whole concept of "premature optimization is the root of all evil" is contrary to the software engineering maxim design first, code second. I'm not familiar with that maxim but it sounds very waterfally. That's a maxim agile developers would have rejected two decades ago. (In fairness this article is from 2009 when agile was still relatively new.)
- beckingz 4y ago
  Though good agile development/product design also spends a lot of time up front determining what is most valuable to do next.
frou_dh 4y ago
This would probably annoy the author of that article, but I must say that I still like the formulation: 1. Make it run. 2. Make it right (Make it correct). 3. Make it fast. ...with the observation that if you complete step 2 then it will often be pretty fast already due to muddy logic having fallen away.
dang 4y ago
Related: The Fallacy of Premature Optimization (2009) - https://news.ycombinator.com/item?id=21912667 https://news.ycombinator.com/item?id=21912667 - Dec 2019 (103 comments) The Fallacy of Premature Optimization (2009) - https://news.ycombinator.com/item?id=13505721 https://news.ycombinator.com/item?id=13505721 - Jan 2017 (59 comments) The Fallacy of Premature Optimization - https://news.ycombinator.com/item?id=10954554 https://news.ycombinator.com/item?id=10954554 - Jan 2016 (1 comment) The fallacy of premature optimization - https://news.ycombinator.com/item?id=1273288 https://news.ycombinator.com/item?id=1273288 - April 2010 (2 comments) The Fallacy of Premature Optimization (sometimes it's good) - https://news.ycombinator.com/item?id=227262 https://news.ycombinator.com/item?id=227262 - June 2008 (4 comments)
sjducb 4y ago
I've always thought it meant: Simplicity + Readability >>> performance If I can look at a method and think of obvious speedups then it was a good method because I could easily read it and be confident about what it does. Loads of performant code is really hard to read because it's full of magic that speeds things up. When you try to modify this code you're never sure if you need to keep the "performance" especially if there's no performance test. I've also done speedups of legacy software. What you find is that most of it is "basically instant" and one method takes 5min. You rewrite that method to be fast, add a performance test to keep it fast, and a big comment explaining exactly why it needs to be fast and how it works.
- GuB-42 4y ago
  > Loads of performant code is really hard to read because it's full of magic that speeds things up. That's if you go down to the lowest levels of optimization. The kind of things you see in compression, hashing, sorting, codecs,... Really hardcore optimization because otherwise, you wouldn't be able to watch that video at without turning your device into an heater, if at all. But in more reasonable cases, simpler code often turns out faster. The less you do, the faster it runs, which is kind of obvious. Readable code is also a good thing for performance, if is easier to see and fix inefficiencies if the code is readable. A good part of performance problems are simply bugs: memory leaks, operations done several times for no reason, etc... and many others are fixable with no loss in readability, for example by using the proper data structure. As for the last part, use a profiler, there is no point optimizing without a profiler. If you don't have a profiler, then good luck, it is doable, like investigating a crash without a stack trace is doable, but it is horrible. One thing I do no matter what: always use the algorithm with the best big-O complexity available, unless you have a good reason not to. You may think you don't have enough data for that O(N^2) or worse to matter, but it can change, in fact, this is the most common type of change, and once you get in the zone, it can get really slow really fast, lookup "accidentally quadratic".
- trashtester 4y ago
  > If I can look at a method My resistance to the term "Premature optimization" is generally not about optimizing single methods, but usually either about optimizing how to split an application up to modules (services, classes methods) or about what technology to use for each component. For instance, if you have an "inner loop" or basic computation unit that requires you to do several REST requests to other services (serially, with little room for parallelism) where it would have been possible to maintaina few hashmaps locally in your service with the same data, you may easily take processing time from 1 hour to 1 week for some computation task. With some experience, you should be perfectly capable of undersanding this way before defining how to split your workloads up into microservices.

54 points by kretaceous 4y ago

osigurdson 4y ago

Unexamined phrase based development is the true root of all evil.

jcelerier 4y ago
"Considered harmful" considered harmful
- beckingz 4y ago
  ""Considered harmful" considered harmful" considered harmful. There are only two hard problems in computer science: "cache invalidation, naming things, and humorous recursion.
- chillfox 4y ago
  I really hate the "X Considered harmful" type of articles, like by who? Inevitably they try to fake a larger consensus where one does not exist. Just be hones and say "I think X is a bad idea"...
  - osigurdson 4y ago
    Exactly. Use simple language. State what you like / dislike about something and provide a compelling argument. Don't try to add false legitimacy with a "considered harmful" title. If your argument has a broad consensus, then state exactly which groups have come to that conclusion.
pif 4y ago
And dogmas, too!
- trashtester 4y ago
  Your dogmas are the heuristics you take for granted that I know to be bad/false, and vice versa. Dogma is the simplifications we teach to children (and students and junior devs) so they don't have to contemplate the full complexity of reality. The problem is when we start to attach our identity to these dogma, and hold them so precious that we will never give them up. Without our dogma/heuristics we get lost. But we need to know how to give up on the ones that are no longer useful.
  - osigurdson 4y ago
    I think you are conflating "dogma" with "mental model". The accepted meaning of "dogma" is a strong belief that adherents are not willing to discuss rationally.
    - gopher_space 4y ago
      He's using the word as a term of art.
    - trashtester 4y ago
      "Dogma" is the word we use to decribe the kind of beliefs other people have that they are not willing to discuss rationally. Most of us will have a hard time recognizing our own dogma. My claim is that we all have things we believe dogmatically. They for the axioms of our mental models. Take away the dogma, and our entire mental framework risks getting shattered. If we completely fail to understand this, though, we are at risk of constructing rationalistic (as opposed to rational) frameworks on top, in believe in them absolutely. This can lead to fanatical movements such as Islamic suicide bombers, "Objetivist" capitalists, Extinctin Rebellion or Conquistador Missionaries. And also all sorts of cargo cults in software development.
      - osigurdson 4y ago
        >> My claim is that we all have things we believe dogmatically. They for the axioms of our mental models. I agree but think of it as a scalar. Some mental models are assigned a "conviction" of 1.0 - that could be considered dogma. Some (like the expectation of what tomorrow's weather might be like) may have a "conviction" of 0.3.

RunSet 4y ago

Hint: If your software ships Chrome its optimization is overdue, not premature. Looking at you, Electron apps.

TeMPOraL 4y ago
Yeah, wish people would apply that to their process. Perhaps going straight for Electron is a premature optimization of the development process.

kasey_junk 4y ago

“Systems that are designed without any thought of performance rarely perform well, even with an extensive optimization phase at the end of the software development cycle.” I’d go further, if performance is not part of your initial requirements you’ll never get it. Performant systems come from architecture and data modeling. Heck in the modern era data load patterns Trump algorithmic efficiency even. Those things are very challenging to back into a codebase.

ngrost24 4y ago

Not sure how I feel about this article... there are some valid points, but also some half-truths, where the answer is more "it depends" than yes or no. The feeling I get is that the article tries to make a long list of all possible causes, which dilutes the main reasons why premature optimisation or even optimisation is skipped. It also doesn't try to see the issue from the other side and inform the reader when optimisation is premature and doesn't need to be considered, which makes its argument very one-sided. One additional point that I think might be missing from this list imo, is the shifting functionality requirements given to the developers which make it less certain that a specific piece of code will be the foundation on which you will build the rest of the logic or whether it will be a leaf-level logic that will be used very infrequently but this comes with other caveats regarding refactoring, etc.

323 4y ago

To quote Andrei Alexandrescu, "Premature optimization is bad, but premature pessimization is also bad".

Gunax 4y ago

The thrust is that Hoare's statement has been misapplied (I agree!) but even moreso: just because someone said it, and someone famous repeats it, does not mean it's true. The statement is really a bit of a tautology: what is 'pre-mature' afterall? Well, it's any optimization that is not going to bear fruit for the user. So the statement might as well be 'optimizations which do not improve the user experience do not improve the user experience'. I see these sort of statements a lot. 'dont add too much salt', or 'dont drive too fast'. They dont really say much other than 'there is some max point which should not be exceeded'. I guess my point is that it doesn't really guide us. Of course any 'pre-mature' optimization is not useful. The difficulty is knowing whether it's pre-mature, which can only gained through experience. I think the reality is that optimizing code is not-fun. Adding features is fun. Writing tests is not-fun. If given the chance, we will find excuses to avoid the not-fun parts of software.

userbinator 4y ago
I think the reality is that optimizing code is not-fun. Adding features is fun. Writing tests is not-fun. If given the chance, we will find excuses to avoid the not-fun parts of software. To what is unfortunately a minority, it's the exact opposite. I enjoy optimising existing code more than adding new code.
jasmer 4y ago
You'll know it when you see it. My gosh man the things I tried to do as a young Eng. myself - some of the tedious things I did to avoid copying strings or this or that! It's hard to see how such things add to 'complexity' in a way that slows down the project. 'Keep it Idiomatic' is a great way to keep things moving and as things become problematic, they can be tweaked. Obviously in some cases that's not going to work.

rossdavidh 4y ago

I have never, in 18 years of professional programming, heard "premature optimization..." used to mean that "you should never optimize your code!" Not saying it never happens, but I have never heard it once used that way. I do occasionally hear it used to mean "don't spend the time to optimize until you have measured whether this is your bottleneck and it will actually matter", or "get it working first so that you know this is actually what you even want, otherwise you will end up optimizing things that get cut soon after". Both of which are valid.

trashtester 4y ago
I've personally, in my 25 years of professional programming, heard it many times to mean "I don't want to consider performance at this stage of development, I want to move ALL optimization to when the code is done." Typically after I've made comments on their design very early in the development process about the code being doomed to be very slow, in a manner that cannot be solved by optimizing small parts of the code later (so will require a rewrite). And I'm not talking about the small wins, that make things 10-50% faster. I'm talking about design mistakes that slow down the code by several orders of magnitude. (Big-O stuff), and that is represented at a point in the design that is so fundamental it's hard to fix without scrapping everything.
JKCalhoun 4y ago
An example might be images used as thumbnails in the UI. If they are fetched over the network, you might as well plan to have a local image cache. No need to wait on that one - and I would not call that premature optimization. Perhaps others would though (ha ha, and perhaps they’re right if there is already a cache in some other hidden part of the pipeline - yes, I am undercutting my own argument).
- peteradio 4y ago
  > if there is already a cache in some other hidden part of the pipeline Still counts as a win, you can IME take out a cache mechanism easily. If somebody wants to ding you for writing excess code I don't know what to tell you, they are probably a-holes.

omginternets 4y ago

Rich Hickey has a succinct quote that reveals the abuse that Hoare's "premature optimization" quote has undergone: the cheapest place to fix bugs is in design. And if we're going to proceed by quotation, another one to consider is Linus Torvalds': Bad programmers worry about the code. Good programmers worry about data structures and their relationships. IMHO, a big thing for junior programmers to unlearn is that one should begin by putting a sloppy version of the program in production, and incrementally improve it thereafter. A little bit of forethought and a bit of attention paid to big-O will do three things: (1) make incremental improvement easier (2) limit the amount of incremental improvement needed, and (3) avoid painting you into a corner wherein significant refactors are needed. As it turns out, thinking ahead of time is not antithetical to shipping code. Quite the contrary.

jasmer 4y ago
I beg to differ. What has to be 'unlearned' is that Engineers think they have a clear vision of what they need to do ... but in reality they don't. This largely has to do with 'unknown unknowns', particularly in requirements. It's actually a much harder concept to learn/unlearn - because we are trained to design towards specs, towards a kind of perfection, to solve problems in which the conditions are contrived. Almost nothing in the academic world prepares people for having to build something whereupon the objectives are a bit fuzzy - especially when said objectives are not presented as fuzzy. It almost requires the 'experience of failure' to grasp that most things that can be incrementally built - should be. The process of building something, is actually a process of 'discovery'. I think that the only time 'prepping far ahead' becomes useful, is when Engineers are building on very foundational, learned knowledge derived from a relevant situation, in which case they are actually acting in an iterative fashion, leveraging knowledge from the previous 'situation' - but even then, I would not consider that for optimization, rather, just keeping a lid on arbitrary complexity. And finally, of course some things are reasonable. You probably are not going to build a high performance codec in Python.
- trashtester 4y ago
  Agree with almost everything above, except the first line. In military strategy there is the quote "Plans Are Worthless, But Planning Is Everything" [1]. I think the same goes for software design. To believe that one can do a complete design of some piece of software, and then implement it precisely as planned, is folly, just as for military plans. Still, it is imperative to do some deep thinking about the purpose of the software as one starts coding, especially about things like the purpose of the software (and what is NOT the purpose), design and design philosophy and expected challenges (including performance challenges) including ideas about how to find solutions to those challenges. Also, after starting to code, it's important to revisit these aspects. Is the purpose changing? If it is, is that good or bad? How do we define the new purpose? Are we making changes to the design? Why? Do we need to refine the design concepts? And so on. Just like for military strategy, this is an art more than a science. We have strong limitations dictated by what is possible, yet it is essential to have an overall idea of what direction we want to move in. Otherwise we, more likely than not, end up with a useless patchwork. [1] https://quoteinvestigator.com/2017/11/18/planning/ https://quoteinvestigator.com/2017/11/18/planning/

deleted 4y ago

[deleted]

lordnacho 4y ago

A lot of coding decisions come down to that elusive idea, judgement. Think about what the pros and cons are, what the scope is, budget, and... decide what to do. I've never come across one of these articles that doesn't boil down to "think about it". That's not to trivialize it, because of course it can take years to hone your development judgement powers, but essentially such articles are only useful so far as they tend to contain a long-form list of commonly encountered thinking points. More specific experience gives you more detailed items on your list. Level 0 of the performance considerations (relevant to every vertical) is maybe whether you can just throw more hardware at it. In my little vertical (finance) you might think about what data structure to use based on what instrument type you're building a system for.

pkilgore 4y ago

"Dogma is the root of more evil"

begueradj 4y ago

Is that really what all premature optimization is about ?

gwbas1c 4y ago

Here's the problem: If you pick a poor framework, pattern, or abstraction at the beginning, and leave optimization to the end... You end up needing to do a significant refactor or rewrite. Translation: Don't suck the entire DB into RAM to read a single value.

Koshkin 4y ago
Translation of translation: leave it for the OS to do it for you :)

gaze 4y ago

Worse is better vs plan carefully is this balance that shows up in every creative field. It’s in writing, in physics, art, everything. Do you try and think carefully up front about what you want to and engineer carefully against what you imagine the requirements to be, or do you hack and slash your way to your goal? Not only is there no right answer, but the right answer changes day by day, hour by hour. It’s the central meta-decision. Making this decision with good judgement is one of the key skills of a good engineer. Someone who applies “worse is better” regardless of the context is a bad engineer. Someone who never finishes anything because they’re overthinking and overabstracting is likewise a bad engineer.

celeritascelery 4y ago

> Observation #6: Software engineers have been led to believe that their time is more valuable than CPU time; therefore, wasting CPU cycles in order to reduce development time is always a win. They've forgotten, however, that the application users' time is more valuable than their time. This is the key thing. I can hardly think of single application where my number one feature request isn’t “make it faster”. Rarely am I interested in a “fresh new look” or “more buttons”. If you can make some task take 5 seconds instead of 10, that is a win for everyone.

pizza234 4y ago
YMMV. I, for example, work in a field where for customers, as long as performance is good enough, features-features-features is the number one priority. Visual Studio Code is actually a good example of "performant enough" software; it's famous (appealing) for its extensibility, but certainly not performance. Then there are cases like Slack or GNOME 3, which were adopted even with lackluster performance. Go figure :|
- TeMPOraL 4y ago
  > I, for example, work in a field where for customers, as long as performance is good enough, features-features-features is the number one priority. There are fields like that. Then there are fields that seem to be like that, but where it's just the person making the purchase decision that cares about "features-features-featues", and actual users don't use most of them and would instead prefer faster software with sane UX. I've definitely seen more of the latter than the former in my life. > Then there are cases like Slack or GNOME 3, which were adopted even with lackluster performance. Go figure :| Nothing to figure out here, it's about who is making the choice, and what choices are available on the market. Slack case is the very common situation of the choice being made by few people (not necessarily best suited for making that choice) for the whole organization / community, and heavily influenced by all the marketing spend and dirty tactics Slack the company did. GNOME 3 is the case of a supplier-driven choice: i.e. some distros defaulted to it for whatever reasons, and people mostly had to accept it, because WM is one but many qualities you care about in a distro, and alone not enough to make you choose a different one. Both types are common situations on the market, and not at all limited to software. To again name them, in short: 1. People making the choice are not the end-users of the product/service. 2. Choice is made by the supplier, and the market doesn't provide an equivalent alternative that made a different choice.

fendy3002 4y ago

People are treating optimization as a zero or one thing. While in fact there are many middle grounds. If we're taking Pareto principle into account, I can say that we can do 20% of optimization to get 80% of the benefit. The more experienced you are, the easier that first 20% is.

Nursie 4y ago

This whole article is a straw man AFAICT. Premature optimisation is not an excuse to avoid thinking about runtime characteristics either at design or implementation time. Premature optimisation is the junior engineer using some cargo-cultish ideas to attempt to shave a couple of instructions off a loop which a) is unlikely to be any sort of bottlneck and b) is going to be picked up by the compiler anyway if it's that simple. It's spending days of effort making some piece of code faster when in practice that piece of code is neither executed often nor on any critical path. "The Fallacy of Premature Optimisation" seems to me to be an article which takes the worst behaviours of people who don't believe in optimisation at all, and uses them to dismiss the entire idea that effort could be misapplied in dead-end microoptimisations that don't achieve anything.

trashtester 4y ago
Maybe you've been more lucky than me, but I've seen plenty of such "junior devs" in positions of influence, with titles such as "senior" or "principal" dev, "architect" or "engineering manager". In many places, titles like that accrue automatically as people get older, especially if they play the political game reasonably well. Some of them will then happily do what you correctly label "Premature optimization" in the microcode, but proceed to make big mistakes in the overall design that leads to several orders of magnitude slowdowns in the general design. I believe the problem is in the training. As junior devs, they may have been scolded for premature optimizations of microcode, but worked within a well thought-out design at the macro level. Then they advance in ranks, and have to do the design part as well, but they never learned to think about the performance at that level, something that benefits a lot from some contemplation up front.

29athrowaway 4y ago

To me, premature optimization is trying to optimize a solution before you understand how it works.

didgetmaster 4y ago

Even though computing resources have grown by leaps and bounds over the past few decades; it seems that the amount of data has grown by even more. I have found that it is much easier to generate twice as much data needed for processing than it is to get the processing of it to run twice as fast. When you multiply by really big numbers, the problem becomes very apparent. A wasted millisecond in a function doesn't seem like much until you call it a million times.

agentultra 4y ago

I always make performance considerations part of my specifications when they matter. Resources are not infinite! Often performances are part of the requirements even though they are implied. Our requirement for a traffic control system might be primarily concerned with the safety of motorists and pedestrians crossing an intersection. However it's generally implied that this system should eventually allow some cars through and some pedestrians through. And that nobody is left waiting too long! Such a system wouldn't be terribly useful if pedestrians never get a chance to cross because the light never changes. It's not premature optimization to design your system with resource constraints in mind. It's smart engineering! A user shouldn't have input lag to scroll a document. The game engine doesn't need to render an infinite number of entities. An HTTP resource shouldn't be returning every record in the database. If you keep these constraints in mind in the design phase you generally end up with a well performing application. Ignoring them is what I've heard called, "premature pessimization," and is a popular source of performance problems in mature applications.

twawaaay 4y ago

I think biggest problem about "premature optimisation" is the problem that defining "premature" has been left to the reader and everybody has their own definition. Then they will spar online completely needlessly because they are comparing apples to oranges. The important thing to remember is that the earlier in development something is fixed, the cheaper it gets. The longer a problem persists throughout the process, the more expensive it will be to fix. And "more" here means "exponentially more". Because at the time of design or discussing with the client I may be able to fix it in a second by just choosing a different option. Once it gets to production it might be either impossible or costs millions and months of development. The job of the person who designs it is to identify which decisions will be hard to undo later if they are found to be wrong and focus on making sure these are done correctly.

zugi 4y ago

> The whole concept of "premature optimization is the root of all evil" is contrary to the software engineering maxim design first, code second. I'm not familiar with that maxim but it sounds very waterfally. That's a maxim agile developers would have rejected two decades ago. (In fairness this article is from 2009 when agile was still relatively new.)

beckingz 4y ago
Though good agile development/product design also spends a lot of time up front determining what is most valuable to do next.

frou_dh 4y ago

This would probably annoy the author of that article, but I must say that I still like the formulation: 1. Make it run. 2. Make it right (Make it correct). 3. Make it fast. ...with the observation that if you complete step 2 then it will often be pretty fast already due to muddy logic having fallen away.

dang 4y ago

Related: The Fallacy of Premature Optimization (2009) - https://news.ycombinator.com/item?id=21912667 https://news.ycombinator.com/item?id=21912667 - Dec 2019 (103 comments) The Fallacy of Premature Optimization (2009) - https://news.ycombinator.com/item?id=13505721 https://news.ycombinator.com/item?id=13505721 - Jan 2017 (59 comments) The Fallacy of Premature Optimization - https://news.ycombinator.com/item?id=10954554 https://news.ycombinator.com/item?id=10954554 - Jan 2016 (1 comment) The fallacy of premature optimization - https://news.ycombinator.com/item?id=1273288 https://news.ycombinator.com/item?id=1273288 - April 2010 (2 comments) The Fallacy of Premature Optimization (sometimes it's good) - https://news.ycombinator.com/item?id=227262 https://news.ycombinator.com/item?id=227262 - June 2008 (4 comments)

sjducb 4y ago

I've always thought it meant: Simplicity + Readability >>> performance If I can look at a method and think of obvious speedups then it was a good method because I could easily read it and be confident about what it does. Loads of performant code is really hard to read because it's full of magic that speeds things up. When you try to modify this code you're never sure if you need to keep the "performance" especially if there's no performance test. I've also done speedups of legacy software. What you find is that most of it is "basically instant" and one method takes 5min. You rewrite that method to be fast, add a performance test to keep it fast, and a big comment explaining exactly why it needs to be fast and how it works.

GuB-42 4y ago
> Loads of performant code is really hard to read because it's full of magic that speeds things up. That's if you go down to the lowest levels of optimization. The kind of things you see in compression, hashing, sorting, codecs,... Really hardcore optimization because otherwise, you wouldn't be able to watch that video at without turning your device into an heater, if at all. But in more reasonable cases, simpler code often turns out faster. The less you do, the faster it runs, which is kind of obvious. Readable code is also a good thing for performance, if is easier to see and fix inefficiencies if the code is readable. A good part of performance problems are simply bugs: memory leaks, operations done several times for no reason, etc... and many others are fixable with no loss in readability, for example by using the proper data structure. As for the last part, use a profiler, there is no point optimizing without a profiler. If you don't have a profiler, then good luck, it is doable, like investigating a crash without a stack trace is doable, but it is horrible. One thing I do no matter what: always use the algorithm with the best big-O complexity available, unless you have a good reason not to. You may think you don't have enough data for that O(N^2) or worse to matter, but it can change, in fact, this is the most common type of change, and once you get in the zone, it can get really slow really fast, lookup "accidentally quadratic".
trashtester 4y ago
> If I can look at a method My resistance to the term "Premature optimization" is generally not about optimizing single methods, but usually either about optimizing how to split an application up to modules (services, classes methods) or about what technology to use for each component. For instance, if you have an "inner loop" or basic computation unit that requires you to do several REST requests to other services (serially, with little room for parallelism) where it would have been possible to maintaina few hashmaps locally in your service with the same data, you may easily take processing time from 1 hour to 1 week for some computation task. With some experience, you should be perfectly capable of undersanding this way before defining how to split your workloads up into microservices.