- rule 1. You can’t tell where a program will spend its time. Bottlenecks happen in surprising places, so don’t second guess and try to employ speed hacks until you’ve proven where the bottleneck is.
- Rule 2. remedy. Don’t tune for speed until you measure, and even then don’t do it until one part of the code dominates the rest.
- Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Don’t get into the fantasy unless you know that n is going to be very large often. (Even if n gets large, use Rule 2 first.)
- Rule 4. Fancy algorithms are worse than simple algorithms, and they are much harder to implement. Use simple algorithms as well as simple data structures.
- Rule 5. Data dominates. If you’ve chosen the right data structures and organized things well, algorithms will almost always be self-evident. Data structures, not algorithms, are at the heart of programming.
Pike’s Laws 1 and 2 reiterate Tony Hoare’s famous saying “Premature optimization is the root of all evil”.
Ken Thompson restated Pike’s Rules 3 and 4 as “When in doubt, use brute force”.
Rules 3 and 4 are examples of the KISS design philosophy.
Rule 5 was first described by Fred Brooks in The Mythical Man-Month. Rule 5 is often abbreviated as “Don’t write stupid code that uses smart objects.”
<a href