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.
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.
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
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.
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'.
> 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.
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.
