3 ms·

And another person finds premature Optimisation. From https://wiki.c2.com/?PrematureOptimization https://wiki.c2.com/?PrematureOptimization Premature optimizat

And another person finds premature Optimisation. From https://wiki.c2.com/?PrematureOptimization https://wiki.c2.com/?PrematureOptimization Premature optimization is the root of all evil -- DonaldKnuth In DonaldKnuth's paper "StructuredProgrammingWithGoToStatements", he wrote: "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%." Write the simplest code first - get it right, if too slow or uses too much resource then set a measurable goal what a good speed or resource needs to be and then optimise until you reach that goal.

iamflimflam1 3y ago
The key part that seems to be ignored by everyone who quotes Knuth is: "Yet we should not pass up our opportunities in that critical 3%"
- n4r9 3y ago
  Exactly. He's not saying "don't think about optimisation until you've written all your code". He's saying "don't try to optimise until you know where it's needed the most". In many cases that does mean write a minimal implementation first. However in some cases knowledge, experience and early profiling will give you some pointers before that.
- wredue 3y ago
  He also didn’t mean to write known to be shitty, slow code, and yet, we have an entire communities of programming paradigms that argue you should do just that, arguing that “premature optimization” is anything that “doesn’t feel fast enough”. What is the definition of “fast enough”? It’s impossible to tell because for those exact same people, they got their guns cocked and ready to fire a “HArDWarE is ChEApER tHAn DEvEloPErs TiMe!!!!!1!1!1!1!1!!” At you the moment you suggest that maybe needing an entire 32 core Xeon server with a tb of ram to serve 20 requests a second is MAYBE in need of optimization.
valenterry 3y ago
Optimizing performance in code is mostly not so important anyways, because it can be done later fairly easily. Architecture (especially infrastructure) are much more critical. Here, if you don't account for performance (or at least performance optimizations later on) then you might run into big problems later.
andrepd 3y ago
Quoting this phrase is a major pet peeve of mine. In an age where applications struggle to do such simple things as displaying text and images when running on supercomputers 10,000x as fast as the ones Knuth had when he wrote this, you know the problem isn't "too much optimisation". What Knuth means is "don't waste time microptimising parts of your code which aren't bottlenecks anyway". Yet when this is cited it's basically taken as "don't give a thought about optimisation until later on, instead do things the easiest way for you as a dev".
- devnullbrain 3y ago
  It's also just something that all engineers do. EEs don't concern themselves about the power-draw of an LED on a space heater. MEs don't work hard to make a piston last 100 years in an engine that will last 10. It boils down to 'focus on important things, not unimportant things'.
- crabmusket 3y ago
  > don't waste time microptimising parts of your code which aren't bottlenecks anyway The irony is that doing so barely optimises anything. The optimisations aren't so much premature as... Not optimisations. I'm a big fan of Casey Muratori's video where he compares 3 things commonly called optimisation: - actual optimisation, which is detailed work involving profilers and evidence - fake optimisation, like using fast inverse square root in a web app because you heard it was faster - non-pessimization, where you just try to write straightforward code without introducing major performance regressions without good reason "Premature optimisation" is probably just "fake optimisation".
kookamamie 3y ago
I really dislike (hate, actually) the premature optimization quote, as it gets misunderstood all the time. Many less experienced developers use it as an excuse of not taking performance considerations into account in design/architecture of a solution. By doing this, they'll notice retrofitting performance to such a design isn't actually trivial.
- throwbadubadu 3y ago
  Exactly, today it seems like an excuse to not think at all, and even if you call out something what will definitely not scale (e.g. your stupid O(n^3) approach will blow up even already going to 100 items, and you know your max will be more around 1000, just as an abstract example)... and those guys laughing at you with premature optimization blah at the same time well knowing and muttering "the prototype becomes the product" and you know where you will end with this planned tech debt having consequences on the whole architecture.. all could have been avoided with just a little more being less lazy and telling bs about premature optimization.
  - wredue 3y ago
    You’re calling this “just an abstract example”, but it’s actually pretty easy to be incredibly slow if you get your ideals from medium articles. The ESB team I have to work with, for example, has a hard cap of 8,000 lines (of XML) in a single file due to their shit performance. Why? “Because recursive, immutable code is ‘easier to reason about’” For starters, I don’t even buy that recursive and immutable cause ease to reasoning, but forgetting that, if it’s causing computers that should be capable of processing files that are millions of lines long to suddenly come to a crawl after just 8,000, we maybe should reconsider this approach.
    - rqtwteye 3y ago
      "The ESB team I have to work with, for example, has a hard cap of 8,000 lines (of XML) in a single file due to their shit performance. Why? “Because recursive, immutable code is ‘easier to reason about’”" Bullshit like this really makes me want to leave the industry. The more "professional" and "business" programming gets, the more bullshit happens.
devnullbrain 3y ago
>Write the simplest code first - get it right, if too slow or uses too much resource then set a measurable goal what a good speed or resource needs to be and then optimise until you reach that goal. So you write the code with algorithm X. You potentially might not know the complexity, depending on how extreme you are with this philosophy, but let's say it's O(n^2). You run it on your test data. It's too slow because of some unneeded deep copies. You change that. Now it's fast enough. It gets merged. 3 years later, you're experiencing integration test failures, because scaling up your system has caused this algorithm to make things time out. No problem: you'll simply look into it and optimise it. Except you can't. Thanks to leaky abstractions, threading-models, or just an inherent quality of the code, changing this algorithm to something with a lower complexity becomes a major refactor. Pray you don't have external APIs or stakeholders depending on it. So, not only have you wasted the time polishing the O(n^2) algorithm, you also now have a huge technical debt from what can simply be described as inadequate forethought. The 'simple code now, polish later' process - which is really just 'move fast and break things' in a different shade of paint - means you never learn to internalise the easy wins. It also paradoxically portrays optimisation as both too complex to do initially but trivial to do later. It's not the latter. Having a good gut-feeling of algorithms or the Kafkaesque way memory works is not something that is learned over the course of a JIRA ticket - it's learned over the course of years, treated as any other code-quality concern. For comparison, you could close many tickets quickly by using a global variable to pass data around. But you don't. You make sensible, idiomatic changes to make sure things are stored and accessible where makes sense. Optimisation is the same: there is a lower bound below which it's unacceptable, even if it's not something that fails requirements. StructuredProgrammingWithGoToStatements was written in 1974. It doesn't track well to modern computing models. I have more L1 cache than he had main memory. I do accept that the vast majority of bugs were from this, 50 years ago. I don't accept that's still true today. It's still a useful thing to teach new learners so they learn how to prioritise their development but as professionals creating novel things we need to have a certain level of planning ahead. And pride. It's also a tautology. If the optimisation is worthwhile, it's not premature. If the optimisation is noncritical, it's premature. My example above is not fanciful, by the way. Off the top of my head, Windows, Python and C++ all had/have trouble with some performance loss due to the fallout from earlier decisions and difficulty rectifying it once the world is built on top of it. I've run into similar problems at my own jobs, particularly anywhere that uses microservices. You can't avoid all of these but you should avoid those you can.
crabmusket 3y ago
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs Do they really? I really don't encounter that. I find premature abstraction more common. But let's assume people are constantly writing for loops instead of using .map... Is that really a bigger problem for software than vague requirements which change before they were even properly understood in the first place? I find this quote really overused and just... Not relevant to my experience as a full stack web developer.
- ant6n 3y ago
  >> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs > Do they really? Well, they probably did fifty years (!) ago, when this quote was written down.
  - crabmusket 3y ago
    Yes I should have been clearer, I didn't mean to suggest it was wrong at the time. Just that it may be wrong now. That could be a limitation of my experience though.
- amadeuspagel 3y ago
  > Do they really? I really don't encounter that. I find premature abstraction more common. There's a pithy quote about that too, by Alan Perlis: "In programming, everything we do is a special case of something more general -- and often we know it too quickly."
jandrewrogers 3y ago
The most important thing for performance is to get the architecture right. You can do micro-optimizations any time but architecture is forever, you typically can't fix that after you've shipped it. Almost all performance in modern systems is architectural in nature. Architecture doesn't live in 3% of your code, it lives in most of it.

iamflimflam1 3y ago

The key part that seems to be ignored by everyone who quotes Knuth is: "Yet we should not pass up our opportunities in that critical 3%"

n4r9 3y ago
Exactly. He's not saying "don't think about optimisation until you've written all your code". He's saying "don't try to optimise until you know where it's needed the most". In many cases that does mean write a minimal implementation first. However in some cases knowledge, experience and early profiling will give you some pointers before that.
wredue 3y ago
He also didn’t mean to write known to be shitty, slow code, and yet, we have an entire communities of programming paradigms that argue you should do just that, arguing that “premature optimization” is anything that “doesn’t feel fast enough”. What is the definition of “fast enough”? It’s impossible to tell because for those exact same people, they got their guns cocked and ready to fire a “HArDWarE is ChEApER tHAn DEvEloPErs TiMe!!!!!1!1!1!1!1!!” At you the moment you suggest that maybe needing an entire 32 core Xeon server with a tb of ram to serve 20 requests a second is MAYBE in need of optimization.

valenterry 3y ago

Optimizing performance in code is mostly not so important anyways, because it can be done later fairly easily. Architecture (especially infrastructure) are much more critical. Here, if you don't account for performance (or at least performance optimizations later on) then you might run into big problems later.

andrepd 3y ago

Quoting this phrase is a major pet peeve of mine. In an age where applications struggle to do such simple things as displaying text and images when running on supercomputers 10,000x as fast as the ones Knuth had when he wrote this, you know the problem isn't "too much optimisation". What Knuth means is "don't waste time microptimising parts of your code which aren't bottlenecks anyway". Yet when this is cited it's basically taken as "don't give a thought about optimisation until later on, instead do things the easiest way for you as a dev".

devnullbrain 3y ago
It's also just something that all engineers do. EEs don't concern themselves about the power-draw of an LED on a space heater. MEs don't work hard to make a piston last 100 years in an engine that will last 10. It boils down to 'focus on important things, not unimportant things'.
crabmusket 3y ago
> don't waste time microptimising parts of your code which aren't bottlenecks anyway The irony is that doing so barely optimises anything. The optimisations aren't so much premature as... Not optimisations. I'm a big fan of Casey Muratori's video where he compares 3 things commonly called optimisation: - actual optimisation, which is detailed work involving profilers and evidence - fake optimisation, like using fast inverse square root in a web app because you heard it was faster - non-pessimization, where you just try to write straightforward code without introducing major performance regressions without good reason "Premature optimisation" is probably just "fake optimisation".

kookamamie 3y ago

I really dislike (hate, actually) the premature optimization quote, as it gets misunderstood all the time. Many less experienced developers use it as an excuse of not taking performance considerations into account in design/architecture of a solution. By doing this, they'll notice retrofitting performance to such a design isn't actually trivial.

throwbadubadu 3y ago
Exactly, today it seems like an excuse to not think at all, and even if you call out something what will definitely not scale (e.g. your stupid O(n^3) approach will blow up even already going to 100 items, and you know your max will be more around 1000, just as an abstract example)... and those guys laughing at you with premature optimization blah at the same time well knowing and muttering "the prototype becomes the product" and you know where you will end with this planned tech debt having consequences on the whole architecture.. all could have been avoided with just a little more being less lazy and telling bs about premature optimization.
- wredue 3y ago
  You’re calling this “just an abstract example”, but it’s actually pretty easy to be incredibly slow if you get your ideals from medium articles. The ESB team I have to work with, for example, has a hard cap of 8,000 lines (of XML) in a single file due to their shit performance. Why? “Because recursive, immutable code is ‘easier to reason about’” For starters, I don’t even buy that recursive and immutable cause ease to reasoning, but forgetting that, if it’s causing computers that should be capable of processing files that are millions of lines long to suddenly come to a crawl after just 8,000, we maybe should reconsider this approach.
  - rqtwteye 3y ago
    "The ESB team I have to work with, for example, has a hard cap of 8,000 lines (of XML) in a single file due to their shit performance. Why? “Because recursive, immutable code is ‘easier to reason about’”" Bullshit like this really makes me want to leave the industry. The more "professional" and "business" programming gets, the more bullshit happens.

devnullbrain 3y ago

>Write the simplest code first - get it right, if too slow or uses too much resource then set a measurable goal what a good speed or resource needs to be and then optimise until you reach that goal. So you write the code with algorithm X. You potentially might not know the complexity, depending on how extreme you are with this philosophy, but let's say it's O(n^2). You run it on your test data. It's too slow because of some unneeded deep copies. You change that. Now it's fast enough. It gets merged. 3 years later, you're experiencing integration test failures, because scaling up your system has caused this algorithm to make things time out. No problem: you'll simply look into it and optimise it. Except you can't. Thanks to leaky abstractions, threading-models, or just an inherent quality of the code, changing this algorithm to something with a lower complexity becomes a major refactor. Pray you don't have external APIs or stakeholders depending on it. So, not only have you wasted the time polishing the O(n^2) algorithm, you also now have a huge technical debt from what can simply be described as inadequate forethought. The 'simple code now, polish later' process - which is really just 'move fast and break things' in a different shade of paint - means you never learn to internalise the easy wins. It also paradoxically portrays optimisation as both too complex to do initially but trivial to do later. It's not the latter. Having a good gut-feeling of algorithms or the Kafkaesque way memory works is not something that is learned over the course of a JIRA ticket - it's learned over the course of years, treated as any other code-quality concern. For comparison, you could close many tickets quickly by using a global variable to pass data around. But you don't. You make sensible, idiomatic changes to make sure things are stored and accessible where makes sense. Optimisation is the same: there is a lower bound below which it's unacceptable, even if it's not something that fails requirements. StructuredProgrammingWithGoToStatements was written in 1974. It doesn't track well to modern computing models. I have more L1 cache than he had main memory. I do accept that the vast majority of bugs were from this, 50 years ago. I don't accept that's still true today. It's still a useful thing to teach new learners so they learn how to prioritise their development but as professionals creating novel things we need to have a certain level of planning ahead. And pride. It's also a tautology. If the optimisation is worthwhile, it's not premature. If the optimisation is noncritical, it's premature. My example above is not fanciful, by the way. Off the top of my head, Windows, Python and C++ all had/have trouble with some performance loss due to the fallout from earlier decisions and difficulty rectifying it once the world is built on top of it. I've run into similar problems at my own jobs, particularly anywhere that uses microservices. You can't avoid all of these but you should avoid those you can.

crabmusket 3y ago

> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs Do they really? I really don't encounter that. I find premature abstraction more common. But let's assume people are constantly writing for loops instead of using .map... Is that really a bigger problem for software than vague requirements which change before they were even properly understood in the first place? I find this quote really overused and just... Not relevant to my experience as a full stack web developer.

ant6n 3y ago
>> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs > Do they really? Well, they probably did fifty years (!) ago, when this quote was written down.
- crabmusket 3y ago
  Yes I should have been clearer, I didn't mean to suggest it was wrong at the time. Just that it may be wrong now. That could be a limitation of my experience though.
amadeuspagel 3y ago
> Do they really? I really don't encounter that. I find premature abstraction more common. There's a pithy quote about that too, by Alan Perlis: "In programming, everything we do is a special case of something more general -- and often we know it too quickly."

jandrewrogers 3y ago

The most important thing for performance is to get the architecture right. You can do micro-optimizations any time but architecture is forever, you typically can't fix that after you've shipped it. Almost all performance in modern systems is architectural in nature. Architecture doesn't live in 3% of your code, it lives in most of it.