Skip to content
Mental Models

Bottlenecks & the Theory of Constraints

Amdahl's Law: The Math of Speedup

There's a hard ceiling on how much faster you can make a system by speeding up one part of it — and a single tidy formula tells you exactly where that wall is, before you waste a dollar trying to climb past it.

12 min Updated Jun 28, 2026

You’ve learned the rule three times now and from three angles: throughput is the minimum, Goldratt’s five steps are the procedure for governing the slowest one, and polishing a non-bottleneck adds exactly zero to what the system delivers. All true, all qualitative. This lesson hands you the number. When someone says “let’s make the database twice as fast,” you’ll be able to answer, on the back of a napkin, “great — that buys us a 1.43x speedup overall, and not one drop more.” The formula that does this is Amdahl’s law, and once it’s in your head you’ll never again be fooled by an impressive-sounding optimization aimed at the wrong place.

Before you read — take a guess

A task spends 90% of its time in step A and 10% in step B. You make step B infinitely fast — instant, zero time, magic. How much faster does the whole task run now?

The setup: every system is part-improvable, part-fixed

In 1967 a computer architect named Gene Amdahl stood up at a conference to argue against the hype around massively parallel computers. His point was arithmetic, not opinion: a program is never entirely parallelizable. Some fraction of it is stubbornly sequential — it has to run start-to-finish on one processor no matter how many you throw at the problem. And that fixed fraction, he showed, puts a hard cap on how much all your extra processors can ever buy you. The argument was about parallel computing, but the math is universal — it applies to anything you can split into “the part I can speed up” and “the part I can’t.”

So set it up generally. Take any task and split its total time into two buckets:

  • The fraction pp of the work you can speed up — the parallelizable stage, the slow query, the manual step you can automate. (pp is between 0 and 1; if 80% of the time is improvable, p=0.8p = 0.8.)
  • The fraction (1p)(1 - p) you can’t — the fixed overhead, the irreducibly sequential bit, the part of the task that’s stuck at its current speed.

Now suppose you speed up the improvable part by a factor ss. Make it twice as fast, s=2s = 2; ten times as fast, s=10s = 10; infinitely fast, ss \to \infty. The question Amdahl answers is the only one that matters: how much faster does the whole task get? Not the part you tuned — the whole thing, end to end, which is what anyone actually cares about.

Tip:

The one-sentence version

Split a task into the part you can speed up (pp) and the part you can’t (1p1-p). However hard you push on pp, the fixed part (1p)(1-p) stays exactly where it was — and it sets a wall you can never cross.

The formula

Here it is, the whole of Amdahl’s law in one line:

Speedup=1(1p)+ps\text{Speedup} = \frac{1}{(1-p) + \dfrac{p}{s}}

“Speedup” means old time divided by new time — a speedup of 2 means the task now runs in half the time. Read the denominator as “the new total time, measured as a fraction of the old total time,” and it falls apart into two honest pieces:

  • (1p)(1-p) — the fixed part, which takes the same time as before. You didn’t touch it, so it contributes its full original share to the new total.
  • ps\dfrac{p}{s} — the improvable part, which used to take pp of the time and now, sped up by a factor ss, takes only p/sp/s. Speed it up 4x and it shrinks to a quarter of its old share.

Add those two and you have the new total time as a fraction of the old; flip it over (the 11 on top) and you have the speedup. That’s it. No calculus, no hidden assumptions — just “the part you fixed got smaller, the part you didn’t stayed the same, add them up and invert.”

Sanity-check it against the pretest. There, p=0.1p = 0.1 (only step B, the 10%, was improvable) and we made it infinite, so p/s0p/s \to 0:

Speedup=1(10.1)+0=10.91.11\text{Speedup} = \frac{1}{(1-0.1) + 0} = \frac{1}{0.9} \approx 1.11

Exactly the 1.11x that felt so disappointing. The formula isn’t lying to you — it’s the same disappointment, made precise.

A report takes 200 seconds to generate: 50 seconds of fixed setup and 150 seconds of number-crunching you can speed up. You make the crunching 3x faster. Using Amdahl's law, what's the overall speedup?

The hard ceiling

Now push ss all the way to infinity — speed up the improvable part perfectly, make it instantaneous, the best you could ever possibly do. The p/sp/s term vanishes, and the formula collapses to something beautiful and brutal:

limsSpeedup=11p\lim_{s \to \infty} \text{Speedup} = \frac{1}{1 - p}

That’s the ceiling. The single most important fact in the whole lesson. No matter how much money, talent, or magic you pour into the improvable part, the overall speedup can never exceed 11p\frac{1}{1-p}, because the part you didn’t fix still has to run. If 25% of the work is un-improvable, then 1p=0.251-p = 0.25 and your ceiling is 1/0.25=41/0.25 = 4x — you could make the other 75% literally instantaneous and the whole task would still only run 4x faster. The fixed part has become the new bottleneck, in exactly the sense lessons 1 through 3 trained you to see. Amdahl’s law is the bottleneck idea written as continuous arithmetic: relieve everything except one stubborn part, and that part becomes the constraint and caps you.

Here’s the ceiling at a few fractions worth memorizing:

Un-improvable fraction (1p)(1-p)Improvable fraction ppMax possible speedup 11p\frac{1}{1-p}
10%90%10x
25%75%4x
50%50%2x
90%10%1.11x

Read the bottom row and feel it: when 90% of the work is stuck, the absolute best you can ever do — perfect, infinite speedup of the other 10% — is a measly 1.11x. That’s the pretest, sitting right there in the table. And notice the table answers a question before you’ve spent a cent: it tells you the most an optimization could ever be worth, which is often reason enough to not bother.

Warning:

The ceiling is set by what you DON'T fix

Your maximum speedup is 1/(1p)1/(1-p) — a number that depends entirely on the fraction you’re leaving alone, and not at all on how clever your optimization is. You can’t out-engineer this wall. The only way to raise the ceiling is to make more of the work improvable (shrink 1p1-p) — which is to say, go attack a bigger part of the problem.

A full worked example

Make it concrete with a data pipeline. Total runtime: 100 minutes. Of that, 80 minutes is a parallelizable transform stage (this is your pp — 80% of the work, so p=0.8p = 0.8) and 20 minutes is fixed overhead: reading the source, writing the result, the sequential glue you can’t parallelize (1p=0.21 - p = 0.2). Your boss wants it faster and asks how much speeding up the transform stage will help. Let’s compute it for a range of efforts and watch what happens.

For each ss, the new time is 20+80s20 + \frac{80}{s} minutes, and the speedup is 100100 divided by that:

Speedup factor ss of the transformNew transform timeNew total timeOverall speedup
1 (do nothing)80 min100 min1.00x
240 min60 min1.67x
420 min40 min2.5x
810 min30 min3.33x
\infty (instant)0 min20 min5x

Walk down that last column. Doubling the transform’s speed (s=2s=2) gets you 1.67x. Going to 4x gets you 2.5x. Going to 8x — eight times faster, a serious engineering effort — gets you only 3.33x. And making it infinitely fast, the theoretical maximum, caps out at 5x (=1/0.2= 1/0.2, straight from the ceiling formula). That 20 minutes of fixed overhead is the wall: even with the transform gone entirely, the pipeline can’t run in less than 20 minutes, so it can’t beat a 5x speedup. Ever.

In that same 100-minute pipeline (80 min improvable, 20 min fixed), your team spends a month getting the transform stage 8x faster, then proposes another month to push it from 8x to 16x. Roughly how much *additional* overall speedup does that second month buy?

Diminishing returns, and where to actually spend

Stare at that worked example and a pattern jumps out: each doubling of ss buys less than the one before. The first doubling (1x → 2x) bought 0.67x of overall speedup. The next (2x → 4x) bought 0.83x. By the time you’re going 8x → 16x you’re scraping up fractions of a fraction. This is the law of diminishing returns, and Amdahl tells you exactly why it bites: as you speed the improvable part up, it shrinks toward zero, so the fixed part takes over as the dominant cost — and you can’t touch the fixed part, by definition. You’re asymptotically slamming into the ceiling.

So where should you spend? The formula answers cleanly: to get the biggest overall speedup, target the biggest pp — the part that eats the most total time. A part with a large pp has a generous ceiling (1/(1p)1/(1-p) is high) and rewards every bit of speedup you give it. A part with a small pp has a ceiling barely above 1x; even infinite cleverness there is wasted. And “find the part that dominates the total time, and push there” is precisely throughput = min and Goldratt’s first focusing step — identify the constraint — dressed up in algebra. Amdahl’s law doesn’t contradict the earlier lessons; it quantifies them. The bottleneck is the stage with the biggest share of the time, the one optimization with real headroom, and the math tells you so.

Match each piece of Amdahl's law to what it means.

Pick a term, then click its definition.

A web request takes 1000 ms: 950 ms in a slow database query and 50 ms in everything else. Sort each proposed optimization by whether it's worth doing.

Place each item in the right group.

  • Rewrite the JSON serializer (part of the 50 ms) to shave 10 ms
  • Micro-optimize the request logger (a few ms of the 50)
  • Hand-optimize the 50 ms of glue code down to 25 ms
  • Add an index that cuts the 950 ms query roughly in half
  • Move the database query to a faster machine (it dominates the time)
  • Cache the database query so it returns in 50 ms instead of 950 ms

When to use it

When to use it

Reach for Amdahl’s law the moment someone proposes an optimization and you want to know — before building it — whether it’s worth the effort. You need two numbers: pp (what fraction of the total time does this part take?) and a guess at ss (how much faster can I realistically make it?). Plug them in. If the answer is “1.1x for three weeks of work,” you’ve just saved three weeks. It’s a five-second filter that catches the most expensive mistake in engineering: pouring effort into a part too small to matter. Profile first to find the big pp, then aim there — Amdahl turns “where should we optimize?” from a debate into an arithmetic problem.

Warning:

The pitfall: optimizing a small slice of the time

You can’t get back more than a part is worth. If something is only 10% of the total time, perfecting it — infinite speedup — buys you at most 1.11x, and any realistic speedup buys far less. The most seductive version of this trap is optimizing the part you understand best or find most fun, rather than the part that’s actually big. Measure the slice before you sharpen the knife: a brilliant fix to a 5% slice is still a rounding error.

State the ceiling rule from memory.

Pick the right option for each blank, then check.

No matter how much you speed up one part of a system, your overall speedup can never exceed , a wall set entirely by the fraction of the work you improve. To raise that ceiling, you must .

Check yourself: the math of speedup

Question 1 of 50 correct

Amdahl's law says overall Speedup = 1 / ((1−p) + p/s). What does the term p/s represent?

Check your answer to continue.

Recap

Big picture

Amdahl's Law — the math of speedup

  • Amdahl's Law
    • The setup
      • Split a task: p = improvable fraction, 1−p = fixed
      • Speed the improvable part up by factor s
      • Gene Amdahl, 1967 — parallel computing, but universal
    • The formula
      • Speedup = 1 / ((1−p) + p/s)
      • (1−p): fixed part, same time as before
      • p/s: improvable part, now shrunken
    • The hard ceiling
      • As s → ∞, speedup → 1/(1−p)
      • Set by the part you DON'T fix, not your cleverness
      • 25% fixed → 4x max; 90% fixed → 1.11x max
      • The fixed part becomes the new bottleneck
    • Diminishing returns
      • Each doubling of s buys less than the last
      • Fixed part dominates as improvable part shrinks
    • Where to spend
      • Target the BIGGEST p — the part that dominates time
      • = throughput is min = identify the constraint
      • Small-p optimizations are capped near 1x — skip them

Where this goes next

You now hold the quantitative key to the whole course: throughput is the minimum, the constraint is whichever part has the biggest pp, and Amdahl’s law tells you in advance exactly how much a fix is worth — ceiling and all. You can look at any proposed optimization and say, before building it, “that’s worth 2x” or “that’s worth nothing,” which is a genuine superpower.

But there’s one twist the math has been quietly hinting at. Speed up the big-pp part enough and it stops being the biggest — some other part now dominates the time, with its own pp, its own ceiling. The constraint didn’t disappear; it moved. The final teaching lesson, The Constraint Always Moves, is about riding that endless game — why fixing one bottleneck always reveals the next, how to cycle through them deliberately (Goldratt’s fifth step: go back to the beginning), and where this never-ending hunt is hiding in your traffic, your team, your queries, and your mornings.

Mark lesson as complete