Your intuition about slowness is usually wrong

A doctor who prescribes surgery based on a guess, without ever running a test — confident, fast, and far too often operating on the wrong thing entirely.

Developers are famously bad at guessing where time goes. The part you're sure is slow is often fine; the real culprit is somewhere you never suspected — a tiny function called a million times, a hidden database call.

Acting on a hunch means you optimise the wrong thing, add complexity, and the program stays slow. The first move is never "fix it" — it's find out where the time actually goes.

The map: 20 concepts in seven groups

A metro map: first you see the whole lines, then you ride station by station.

The course's concepts fall into seven groups — one per chapter. First, how to measure. Then which kind of "fast" you need. Then the bottleneck and the classic fixes for it. Then how not to be fooled by the average, when not to optimise, and how to run the whole thing as a loop.

How to read this course

A mechanic doesn't swap parts at random: instruments first, then one fix, then a re-test.

Every concept gets the same treatment: its English name (remember it — it's the term in docs, profilers, and dashboards), a picture from everyday life, a diagram, and a card with what it is, how it works, example, catch, and related.

The big idea: performance isn't a bag of tricks, it's a method. Measure → find the bottleneck → fix that one thing → measure again → stop at a target. Everything else in the course is detail inside that loop.

Profiling — find the real cost

An itemised bill that shows exactly where the money went, line by line — so you stop guessing and see that one charge, not the ones you assumed, ate the budget.

A profiler is a tool that measures where your program actually spends its time, function by function. It turns "I think this is slow" into "this one function is 80% of the runtime." With that, you fix what matters instead of what you imagined.

Whether it's a profiler, timing logs, or your observability metrics, the principle holds: let measurement, not intuition, point you at the problem.

Measure–Fix–Measure — measure, fix, measure again

A scientist changes one variable, re-runs the experiment, and checks the result — never assuming a change helped, always confirming it did.

Performance is a loop: measure to find the slow part, change it, then measure again to confirm the change actually helped — and didn't just move the problem or make it worse.

Without the second measurement you're guessing whether you improved anything, which is how "optimisations" quietly make things slower. Treat every fix as a hypothesis you verify — the same discipline as evals for AI or tests for code.

Latency — the wait for one thing

How long a single coffee takes from order to cup — one customer's experience, measured start to finish.

Latency is how long one operation takes from start to finish — one request, one page load, one query. It's what an individual user feels: the wait.

When someone says "the site is slow," they almost always mean latency — the delay between doing something and getting a response. Lowering latency is about making each single thing happen faster.

Throughput — how much you handle per second

How many coffees the whole café serves an hour — not how long one takes, but the total flow through the shop.

Throughput is how much work the system handles per unit of time — requests per second, jobs per minute. It's about total capacity, not individual wait.

A system can have great throughput (serving thousands at once) while each user still waits a while (high latency), or low latency but limited capacity. They're different goals, and which one you're chasing changes what you fix.

Batching — throughput at the cost of latency

A motorbike gets one person there fastest (low latency); a bus moves the most people per trip (high throughput). The best vehicle depends on which you need.

Latency and throughput are independent, and optimising one can hurt the other. Batching — grouping work together — often raises throughput but adds latency, because each item waits for the batch.

So you have to decide which matters here: a user-facing page lives or dies on latency; a background data pipeline cares about throughput. Naming your real goal keeps you from optimising the number that doesn't matter to your users.

Bottleneck — one slow part dominates

A chain is exactly as strong as its weakest link — reinforcing the strong links does nothing; only the weak one decides whether it holds.

In most slow systems, a single bottleneck accounts for the bulk of the time — one query, one slow service, one bad loop. Everything else is already fast enough.

This is why guessing is so wasteful: the whole skill is locating the dominant cost, not improving the fast parts.

Limiting Step — the system is only as fast as its slowest step

A highway that's wide open until one lane-closure where every car crawls — the whole journey's speed is set by that one chokepoint, not the clear stretches.

A request that flows through ten steps is limited by the slowest one — the limiting step. Speeding up the nine fast steps barely moves the total; the slow step sets the pace. So you target the chokepoint specifically.

And note that fixing one bottleneck often reveals the next: remove the slowest step and a new slowest step emerges. Performance work is iteratively finding and clearing whatever is limiting the system right now.

Amdahl's Law — optimising elsewhere is wasted effort

Polishing the trophy while the car has a flat tyre — effort spent where it changes nothing, while the thing that actually stops you sits ignored.

Optimise a part that's only 2% of the runtime and the best you can win is 2%. Find the part that's 80%, and fixing it transforms everything. This arithmetic is called Amdahl's law: your gain is capped by the share of time the part you speed up actually takes.

Time spent optimising anything but the bottleneck is, by definition, time that can't meaningfully help. It often makes things worse, adding complexity and bugs for an invisible gain. Measurement stops you from lovingly optimising the part you understand and forces you onto the part that actually costs. Fix the bottleneck, ignore the rest — until the rest becomes the bottleneck.

Better Algorithm (Big-O) — a better algorithm beats a faster machine

Two routes to the same city: a faster car on the long winding road still loses to a slower car on the straight shortcut. The route matters more than the engine.

The biggest wins often come from a better algorithm or data structure, not faster hardware or micro-tweaks. Big-O describes how the time grows as the input grows. An O(n²) loop replaced with an O(n) hash-map lookup can turn minutes into milliseconds — a change no amount of faster machine could match.

Before optimising the small stuff, ask whether the approach is wrong. A better shape, as the data-structures course shows, is the cheapest and largest speedup there is.

N+1 Query — too many round trips

Making twenty separate trips to the shop for one item each, instead of one trip with a list — the travel, not the shopping, is eating your afternoon.

A huge amount of slowness is too many round trips — repeated calls to a database or service, each cheap alone but devastating in bulk.

The classic is the N+1 query: fetching a list, then making one more query per item, turning one trip into hundreds. The fix is to fetch in bulk — ask for everything at once. Reducing the number of trips usually beats speeding up each one, because the round trip itself is the cost.

Caching — don't compute the same thing twice

Re-cooking a meal from scratch every time someone asks for it, instead of keeping a pot warm — the fastest work is the work you don't repeat.

Caching — remembering an expensive result so you don't recompute it — is one of the biggest levers there is (it has its own course).

The first request takes the slow path and saves the result; the next ones get it from memory. The price is memory and the risk of serving stale data.

Doing Less — the fastest work is the work you skip

Not cooking what nobody ordered, and not laying the table for twenty when three turned up.

One more classic — doing less. Compute things lazily, only when actually needed; avoid loading data you won't use; skip work whose result you'll throw away.

The fastest operation is the one you never run. Often the best optimisation isn't doing the work faster — it's not doing it at all.

Average — the average hides the slow cases

A room with nine comfortable people and one on fire has a pleasant average temperature — the mean erases the case that actually matters.

Reporting performance as an average (the mean) is dangerously soothing: it blends the fast majority with the slow few into one happy number. But users don't experience the average — each user experiences their request, and the slow ones feel every millisecond.

An average response time of 200 ms can hide that one user in twenty waits five seconds. The mean tells you the system is fine while a real slice of your users suffer.

Percentiles — p50 and p99 show the real experience

A report that says not just the typical wait but "the slowest 1% of people waited this long" — naming the bad experiences instead of averaging them away.

Percentiles capture what the average hides. p50 (the median) is the typical case — half are faster. p99 is the slow tail — 99% are faster, so it's roughly the worst experience a real user hits.

Watching p99, not just the average, is how you see the users who are actually suffering. The tail is where the pain lives, and percentiles are how you make it visible.

Tail Latency — what users remember

One terrible meal at a restaurant outweighs a dozen fine ones in someone's memory — the worst experiences, not the average, shape how people judge you.

The slow requests — the tail latency — disproportionately shape how users perceive your product, because a bad experience sticks.

And at scale, the tail hits more people than it seems: if every page makes many calls, the chance that at least one is slow grows fast, so almost every user eventually feels the tail. This is why serious teams set targets on p99, not averages: taming the worst cases is what makes a product feel reliably fast.

Premature Optimization — the root of all evil

Reinforcing every wall of a house against an earthquake that may never come, before anyone has even moved in — enormous effort spent on a problem you don't yet have.

Donald Knuth's famous line — "premature optimization is the root of all evil" — warns against optimising before you know what, or whether, anything needs it.

Optimising code that isn't slow, or isn't even run much, buys nothing and costs plenty: complexity, bugs, and time stolen from things that matter. Most code doesn't need to be fast; it needs to be correct and clear. Speed work is for the parts measurement proves are hot.

Correct → Clear → Fast — clear and correct first, fast where it counts

You write the recipe so anyone can follow it, and only streamline the one step you make a hundred times a day — not every step, just the hot one.

The order is: make it correct, make it clear, and make it fast only where measurement shows it matters.

Clear code is easier to optimise later precisely because you can understand it; tangled "fast" code is hard to fix when the real bottleneck appears elsewhere. Optimising for speed almost always costs readability, so you spend that cost only where it buys a real, measured win — and keep the rest simple.

Performance by Design — but don't ignore performance in the design

You don't earthquake-proof a shed, but you also don't build a skyscraper on sand — some choices are cheap to get right early and ruinous to fix late.

The warning isn't "never think about performance." Choosing an O(n²) algorithm where an O(n) one was just as easy, or a structure that won't scale, is a design mistake you'll pay for dearly later.

The balance: don't micro-optimise early, but don't make architectural choices that are slow by design and expensive to undo. Get the big shape right cheaply up front; optimise the details only when measurement demands it.

Optimization Loop — measure, fix the bottleneck, repeat

A mechanic diagnoses with instruments, fixes the one failing part, then re-tests — never replacing random parts hoping the noise goes away.

The method is simple and disciplined: measure to find the bottleneck, fix that one thing, measure again to confirm and to reveal the next bottleneck, and stop when it's fast enough.

Each pass targets the current dominant cost and ignores everything else. This loop keeps performance work honest and efficient — you always know you're working on the thing that actually matters, and you always know whether you helped.

Performance Target — set a target, then stop

You insulate the house until it's warm enough, then stop — you don't keep adding insulation forever past the point anyone can feel.

Performance has no natural end — you can always make something marginally faster. So set a performance target ("pages under 300 ms at p99") and stop when you hit it.

Without a goal, optimisation becomes an endless time-sink with diminishing returns, and complexity creeps in for gains nobody notices. Knowing what "fast enough" means — for your users, your use case — is what lets you do exactly enough performance work and then go build something else.

How it all fits together

The whole route on one map: where you start, which stations you pass, and where you get off.

The concepts form one picture. Profiling finds the bottleneck; the goal — latency or throughput — tells you what to fix. The bottleneck is usually cured by one of four classics: a better algorithm, fewer round trips, a cache, or doing less. Then you measure again, by percentiles, against a target, and stop. And premature optimisation is what happens when you skip the measuring.