make the common case fast

Suppose you are redesigning a busy airport. You could spend your whole budget gold-plating the rarely-used cargo terminal, or you could widen the security lines that every single passenger waits in. The wise choice is obvious: improve the thing that happens most often, because that is where the time is actually spent. 'Make the common case fast' is this principle applied to computers — find what the machine does most, and pour your effort there.

Concretely, this guiding principle of architecture says: identify the frequent, simple events and optimize those, even at the cost of making the rare, complex events a little slower. Adders are built to be fast for the overwhelmingly common case of adding two normal numbers, while exotic corner cases can take extra cycles. Caches make the common case — accessing data you used recently — fast, while the rare cache miss pays a heavy penalty. The justification is quantitative and comes straight from Amdahl's law: the time you can save is proportional to how often a case occurs times how much you speed it up, so a modest improvement to something that happens 90 percent of the time beats a dramatic improvement to something that happens 1 percent of the time.

The honest caveat is that 'common' must be measured, not guessed. Programmers are notoriously bad at predicting where their programs spend time; the actual hot spot is often a surprise. So the principle has a partner: profile first, then optimize. Speeding up a rare path feels productive but moves the overall number almost not at all — this is exactly the trap Amdahl's law warns about. The discipline is to let measurement, not intuition, tell you which case is common, and then make that one fast.