[nsguy]

That's not my interpretation. If you're profiling and benchmarking you're already engaging in (premature) optimization. This process you're describing of finding out whether `i++` is taking a lot of CPU time and then changing it is exactly what Knuth is saying not to worry about for 97% of your code. Knuth is saying it doesn't matter if `i++` is slow if it's in a non-performance critical part of your code. Any large piece of software has many parts where it doesn't matter for any practical purpose how fast they run and certainly one loop in that piece of software doesn't matter. For example, the software I'm working on these days has some fast C code and then a pile of slow Python code. In your analogy all the Python code is known to be much slower than the C code, we don't need a profiler or benchmarks to tell that, but it also doesn't matter because the core performant functionality is in that C code.

[randomdata]

Knuth says forget about small efficiencies in 97% of your code. Indeed, the `i++` optimization isn't apt to make more than a small difference, even with the most naive compiler, but other decisions could lead to larger chasms. It seems he is still in favour of optimizing for the big wins across the entire codebase, even if it doesn't really matter in practice.

But it's your life to live. Who cares what someone else thinks?