4 ms·

Am I right in thinking #5 is asking for premature optimization? I thought that was generally discouraged

deleted 9y ago
[deleted]
quotheth 9y ago
The "premature optimization is the root of all evil" thing is totally blown out of proportion. I think what they're saying is don't use that quote as a reason to write garbage slow code.
artimaeis 9y ago
To me #5 is talking about the myth that surrounds premature optimization. That is - this idea that thinking through data patterns (or other basic aspects of code) early on is a waste of time. It's usually not. Making the choice to work with collections that can be accessed in O(log n) rather than O(n^2) is a trivial optimization. Maybe you don't need to scope out every subroutine, but taking the time to review the basic performance features is something we can all strive to do.
maxxxxx 9y ago
The premature optimization thing is often used as an excuse to write plainly stupid code without any thought. I think that's what #5 is about.
- kragen 9y ago
  Several times I've heard novice programmers cite the "premature optimization" saw as an argument against doing things that weren't optimization at all. Handling edge cases correctly, for example, or throwing exceptions instead of returning incorrect results, or handling two input formats instead of one, or tolerating trailing whitespace on input. "Optimization" means "making code run faster without changing what it does". If you're changing the code's behavior in an observable way, that's not optimization.
  - maxxxxx 9y ago
    Also things like copying huge arrays back and forth or hammering the database repeatedly.
curtis3389 9y ago
I think the author's point is that even if "premature optimization is the root of all evil" is true, that doesn't mean you write a naive, brute-force solution for every problem.
jandrese 9y ago
I think there is a difference between "premature optimization" and putting thought into what you are actually asking the computer to do when you write some code. You aren't hand unrolling loops and rewriting stuff in assembler on the first pass, you're thinking to yourself "doing it this way is going to require n! iterations, but if I restructure my internal data layout I can reduce it to n log n at the cost of only a few megabytes of memory." The trick here is that you have to understand what each tool is doing before you use it, and that's the opposite of what computer languages are driving towards these days. There is a big push towards abstracting away the actual work, potentially so the compiler can apply optimizations under the hood, but this requires the programmer to either know tons of details about what the compiler does, or to trust it implicitly and hope they don't write code that is grossly inefficient. Or maybe what you do is grossy inefficient, but it can be automatically parallelized well so you don't notice it too much.
closeparen 9y ago
There’s a difference between abstaining from language features and writing things in obtuse ways “because performance,” vs. putting some thought into how the process is going to work and making reasoned choices.
- AstralStorm 9y ago
  This is often called with a flowery phrase "Machine Sympathy". The problem begins where deadlines are too close to fix minor inefficiencies...
deleted 9y ago
[deleted]
sbov 9y ago
The full Knuth quote: "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%" Keywords: small efficiencies. How it's usually used: I shouldn't think about performance up front at all.
- AstralStorm 9y ago
  Counterpoint: small inefficiencies add up, ruining throughput and latency in a bigger codebase. Nothing teaches this better than seeing code making thousands of ephemeral objects in Java in a heap profiler and getting GC stalls with no big place to fix.
dr0verride 9y ago
To me, #5 is calling out developers that write sloppy, thoughtless and obviously inefficient code and then claim premature optimization when someone comments on the quality of that code.

deleted 9y ago

[deleted]

The "premature optimization is the root of all evil" thing is totally blown out of proportion. I think what they're saying is don't use that quote as a reason to write garbage slow code.

artimaeis 9y ago

To me #5 is talking about the myth that surrounds premature optimization. That is - this idea that thinking through data patterns (or other basic aspects of code) early on is a waste of time. It's usually not. Making the choice to work with collections that can be accessed in O(log n) rather than O(n^2) is a trivial optimization. Maybe you don't need to scope out every subroutine, but taking the time to review the basic performance features is something we can all strive to do.

maxxxxx 9y ago

The premature optimization thing is often used as an excuse to write plainly stupid code without any thought. I think that's what #5 is about.

kragen 9y ago
Several times I've heard novice programmers cite the "premature optimization" saw as an argument against doing things that weren't optimization at all. Handling edge cases correctly, for example, or throwing exceptions instead of returning incorrect results, or handling two input formats instead of one, or tolerating trailing whitespace on input. "Optimization" means "making code run faster without changing what it does". If you're changing the code's behavior in an observable way, that's not optimization.
- maxxxxx 9y ago
  Also things like copying huge arrays back and forth or hammering the database repeatedly.

curtis3389 9y ago

I think the author's point is that even if "premature optimization is the root of all evil" is true, that doesn't mean you write a naive, brute-force solution for every problem.

jandrese 9y ago

I think there is a difference between "premature optimization" and putting thought into what you are actually asking the computer to do when you write some code. You aren't hand unrolling loops and rewriting stuff in assembler on the first pass, you're thinking to yourself "doing it this way is going to require n! iterations, but if I restructure my internal data layout I can reduce it to n log n at the cost of only a few megabytes of memory." The trick here is that you have to understand what each tool is doing before you use it, and that's the opposite of what computer languages are driving towards these days. There is a big push towards abstracting away the actual work, potentially so the compiler can apply optimizations under the hood, but this requires the programmer to either know tons of details about what the compiler does, or to trust it implicitly and hope they don't write code that is grossly inefficient. Or maybe what you do is grossy inefficient, but it can be automatically parallelized well so you don't notice it too much.

closeparen 9y ago

There’s a difference between abstaining from language features and writing things in obtuse ways “because performance,” vs. putting some thought into how the process is going to work and making reasoned choices.

AstralStorm 9y ago
This is often called with a flowery phrase "Machine Sympathy". The problem begins where deadlines are too close to fix minor inefficiencies...

deleted 9y ago

[deleted]

sbov 9y ago

The full Knuth quote: "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%" Keywords: small efficiencies. How it's usually used: I shouldn't think about performance up front at all.

AstralStorm 9y ago
Counterpoint: small inefficiencies add up, ruining throughput and latency in a bigger codebase. Nothing teaches this better than seeing code making thousands of ephemeral objects in Java in a heap profiler and getting GC stalls with no big place to fix.

dr0verride 9y ago

To me, #5 is calling out developers that write sloppy, thoughtless and obviously inefficient code and then claim premature optimization when someone comments on the quality of that code.