Top
Best
New

Posted by signa11 6/26/2025

Revisiting Knuth's “Premature Optimization” Paper(probablydance.com)
193 points | 141 commentspage 3
skeezyboy 4 days ago|
the reason were still arguing over this is because knuth cant say things concisely; he didnt communicate this idea succintly enough
skeezyboy 23 hours ago|
howd i get downvoted for that
userbinator 5 days ago||
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 5 days ago||
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 5 days ago|
That's literally the first sentence of the article.
wewewedxfgdf 5 days ago|
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 5 days ago|
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.