3 ms·

It is not true that you can not "theoretically" (read: based on formal reasoning) model program performance. You don't need to run a program to determine that a

It is not true that you can not "theoretically" (read: based on formal reasoning) model program performance. You don't need to run a program to determine that an O(n^2) approach will be slower than an O(log n) algorithm. You do not need to run a program to determine the impact of optimizing a bit of your para code; you can get fairly good sense using Amdahl's law. Etc. Like his creation, the Go language, Rob Pike's rules are somewhat condescending and patronizing those he deems as lesser programmers. Rule 3, however, is the exception. That is the take away gem based on experience.

inimino 9y ago
> You don't need to run a program to determine that an O(n^2) approach will be slower than an O(log n) algorithm. That depends on N and on the constant factors. Which means testing still might surprise you. More to the point, if the O(n^2) algorithm is simpler and leaves you more time for profiling and fixing actual performance issues after the code works, you may end up with faster code by doing the dumb thing.