Top
Best
New

Posted by signa11 6/26/2025

Revisiting Knuth's “Premature Optimization” Paper(probablydance.com)
194 points | 141 commentspage 3
skeezyboy 6/30/2025|
the reason were still arguing over this is because knuth cant say things concisely; he didnt communicate this idea succintly enough
skeezyboy 7/4/2025|
howd i get downvoted for that
userbinator 6/29/2025||
I understood it to mean that optimising for speed at the expense of size is a bad idea unless there are extremely obvious performance improvements in doing so. By default you should always optimise for size.
ethan_smith 6/30/2025||
The famous "premature optimization" quote isn't from a dedicated paper on optimization, but from Knuth's 1974 "Structured Programming with go to Statements" paper where he was discussing broader programming methodology.
tyrust 6/30/2025|
That's literally the first sentence of the article.
wewewedxfgdf 6/29/2025|
It's no longer relevant. It was written when people were writing IBM operating systems in assembly language.

Things have changed.

Remember this: "speed is a feature"?

If you need fast softwqare to make it appealing then make it fast.

hinkley 6/29/2025|
I will say I have worked on projects where sales and upper management were both saying the same thing: customers don't like that our product is slow(er than a competitors), and the devs just shrug and say we've already done everything we can. In one case the most senior devs even came up charts to prove this was all they were going to get.

Somehow I found 40%. Some of it was clever, a lot of it was paying closer attention to the numbers, but most of it was grunt work.

Besides the mechanical sympathy, the other two main tools were 1) stubbornness, and 2) figuring out how to group changes along functional testing boundaries, so that you can justify making someone test a change that only improves perf by 1.2% because they're testing a raft of related changes that add up to more than 10%.

Most code has orphaned performance improvements in 100 little places that all account for half of the runtime because nobody can ever justify going in and fixing them. And those can also make parallelism seem unpalatable due to Amdahl.