4 ms·

Don't forget "Premature optimization is the root of all evil"

klysm 6y ago
I kind of dislike this quote because performance matters a great deal and it should be a design goal before code is even written imo which I guess would be as “premature” as possible
- okareaman 6y ago
  I don't think it's a critique of writing performant code. I always took it to mean don't optimize your code before you know where the bottlenecks are. For example, I could spend a lot of time on a Boyer Moore string matching algorithm only to find later that my program actually spends very little time searching strings.
  - Gibbon1 6y ago
    I think of that quote as being in the context of the sorts of 'music box' programs people were writing in the 1970's. This little gear also has a cam that operated the ballerina's arm. It's the sort of thing you do when you need to stuff a FORTRAN compiler in 32k of memory. If you write your code right then refactoring it to use a different more whatever algorithm should be if not easy at least 'not hard'.
  - qes 6y ago
    > I could spend a lot of time on a Boyer Moore string matching algorithm Could you? It's like an hour to copy/paste a reference implementation and set up unit tests. Maybe an hour or two fine tuning the implementation for your language and benchmarking some use cases. I'd been using the same C# Boyer-Moore impl for like 15 years, and happened to have just recently updated it for Span support. I doubt I have 8 hours into it in total, and it's thoroughly benchmarked and tested.
    - okareaman 6y ago
      You're missing my point. Pick coding up something that for you would be an egregious waste of your time on this earth.
- db48x 6y ago
  It's one thing to design a program such that it can be fast, and quite another to focus on some random piece of code and spend weeks optimizing it, only to find out later that the performance of that particular piece of code was irrelevant.
- AnHonestComment 6y ago
  Early isn’t necessarily premature. I always took the quote to mean you should focus on the right optimizations at the right time — starting with architectures and algorithms that alleviate as much work as possible (big savings) and only then get into code level optimizations (small savings). Architecture and algorithm design is where you get your “big O” wins, while code optimizations get you that last scaling factor of efficiency. It’s a retort to people who micro-optimize an HTTP response... while having a process that generates 10x the API calls it needs to by not caching or joining data.
CyberDildonics 6y ago
This quote does a lot damage in modern times because people forget the context it was said. Donal Knuth said this when talking about programmers decades ago trying to noodle loops and expressions while they were writing them. In the modern era the same optimizations aren't even necessary at all, because the small stuff is done by the compiler. People think it is a good plan to throw caution to the wind and figure out speed later, which just isn't true. You have to architect for throughput, latency and interactivity from the start and language does matter.
- dblohm7 6y ago
  Obligatory: https://ubiquity.acm.org/article.cfm?id=1513451 https://ubiquity.acm.org/article.cfm?id=1513451
  - okareaman 6y ago
    fortunately, I never misunderstood the original intent of Tony Hoare and Donald Knuth
dblohm7 6y ago
I think this quote is much better if we modify it by s/optimization/micro-optimization/
dragontamer 6y ago
Said Knuth, who was literally writing examples in assembly talking about why decrement loops are slightly faster than increment loops in the same section. IIRC, that section (maybe the same page) was also talking about loop unrolling and counting the number of cycles used in various situations. Not big O, literally the cycle count in the MIX architecture.

I kind of dislike this quote because performance matters a great deal and it should be a design goal before code is even written imo which I guess would be as “premature” as possible

okareaman 6y ago
I don't think it's a critique of writing performant code. I always took it to mean don't optimize your code before you know where the bottlenecks are. For example, I could spend a lot of time on a Boyer Moore string matching algorithm only to find later that my program actually spends very little time searching strings.
- Gibbon1 6y ago
  I think of that quote as being in the context of the sorts of 'music box' programs people were writing in the 1970's. This little gear also has a cam that operated the ballerina's arm. It's the sort of thing you do when you need to stuff a FORTRAN compiler in 32k of memory. If you write your code right then refactoring it to use a different more whatever algorithm should be if not easy at least 'not hard'.
- qes 6y ago
  > I could spend a lot of time on a Boyer Moore string matching algorithm Could you? It's like an hour to copy/paste a reference implementation and set up unit tests. Maybe an hour or two fine tuning the implementation for your language and benchmarking some use cases. I'd been using the same C# Boyer-Moore impl for like 15 years, and happened to have just recently updated it for Span support. I doubt I have 8 hours into it in total, and it's thoroughly benchmarked and tested.
  - okareaman 6y ago
    You're missing my point. Pick coding up something that for you would be an egregious waste of your time on this earth.
db48x 6y ago
It's one thing to design a program such that it can be fast, and quite another to focus on some random piece of code and spend weeks optimizing it, only to find out later that the performance of that particular piece of code was irrelevant.
AnHonestComment 6y ago
Early isn’t necessarily premature. I always took the quote to mean you should focus on the right optimizations at the right time — starting with architectures and algorithms that alleviate as much work as possible (big savings) and only then get into code level optimizations (small savings). Architecture and algorithm design is where you get your “big O” wins, while code optimizations get you that last scaling factor of efficiency. It’s a retort to people who micro-optimize an HTTP response... while having a process that generates 10x the API calls it needs to by not caching or joining data.

CyberDildonics 6y ago

This quote does a lot damage in modern times because people forget the context it was said. Donal Knuth said this when talking about programmers decades ago trying to noodle loops and expressions while they were writing them. In the modern era the same optimizations aren't even necessary at all, because the small stuff is done by the compiler. People think it is a good plan to throw caution to the wind and figure out speed later, which just isn't true. You have to architect for throughput, latency and interactivity from the start and language does matter.

dblohm7 6y ago
Obligatory: https://ubiquity.acm.org/article.cfm?id=1513451 https://ubiquity.acm.org/article.cfm?id=1513451
- okareaman 6y ago
  fortunately, I never misunderstood the original intent of Tony Hoare and Donald Knuth

dblohm7 6y ago

I think this quote is much better if we modify it by s/optimization/micro-optimization/

dragontamer 6y ago

Said Knuth, who was literally writing examples in assembly talking about why decrement loops are slightly faster than increment loops in the same section. IIRC, that section (maybe the same page) was also talking about loop unrolling and counting the number of cycles used in various situations. Not big O, literally the cycle count in the MIX architecture.