speedup

You found a faster route to work. The old way took 60 minutes; the new way takes 40. How much better is the new way? You divide: 60 over 40 is 1.5, so the new route is 1.5 times faster — a speedup of 1.5. Speedup is just this ratio of old time to new time, and it is the cleanest way to say how much an improvement actually helped, far clearer than vague phrases like 'a lot faster.'

Formally, speedup equals the execution time before an improvement divided by the execution time after. If a program took 100 seconds and now takes 25, the speedup is 100/25 = 4 — it is four times as fast. Notice the direction: time goes in the denominator after, so a bigger speedup means less time. People sometimes muddle this with percentages: a speedup of 4 means a 75 percent reduction in time, not '400 percent faster' in a way that maps cleanly to everyday speech, so it is safest to quote the ratio.

Speedup is the language in which Amdahl's law speaks, and that is its most important honest lesson. If you only speed up part of a program, the part you did not touch limits the overall gain. Make a portion that is 40 percent of the run time twice as fast and you do not get a 2x overall speedup — you get 1 divided by (0.6 plus 0.4/2), which is about 1.25. This is why 'make the common case fast' matters: the speedup you actually realize is governed by how big a slice of the total time you improved, not by how dramatically you improved that slice.