Latency numbers every programmer should know, and why


A mantis shrimp can throw a punch so fast the water around its claw boils. Not metaphorically — cavitation bubbles form and collapse from the sheer speed of the strike, and the flash of light and heat from that collapse is briefly hotter than the surface of the sun, in a volume smaller than a grain of rice1. The shrimp is about four inches long. It has no idea any of this is happening. It just really wants to eat a snail.

Your CPU is doing something similar. It’s worth actually knowing the numbers behind that, because almost every performance problem is about the distance to the data.

The hierarchy

Here’s the shape of it, roughly in order of distance from the core2:

Latency across the memory and network hierarchy, log scale

That’s the whole spectrum, top to bottom: half a nanosecond to a hundred and fifty million nanoseconds. A factor of roughly 300 million between the fastest and slowest thing on this list.

The log scale on that chart is doing real work — plotted on a normal linear axis, everything from L1 through main memory would collapse into a single sliver of pixels against the network bars at the far end. That flattening is itself part of the point: on a linear scale most of this hierarchy is invisible, which is a decent metaphor for how easy it is to lose track of costs sitting well below a request or a database call in cost.

Making that gap feel real

Numbers like “0.5 ns” and “150 ms” don’t mean anything intuitively side by side, so here’s a way to ground them that isn’t just a metaphor — it’s actually true. Light travels at a fixed, known speed. So for any latency number, you can ask a very literal question: how far would light get in that amount of time?

If latency were distance: how far light travels in each tier's access time

An L1 cache reference, 0.5 nanoseconds, is about how long it takes light to cross a coffee mug. Main memory, 100 nanoseconds, is roughly the length of a blue whale. An SSD random read, 150 microseconds, covers about 45 kilometers — roughly the distance from Brussels to Antwerp. A same-datacenter network round trip, half a millisecond, covers about 150 kilometers, in the neighborhood of Cologne to Frankfurt. A disk seek, 10 milliseconds, would cover about 3,000 kilometers if it were light instead of a mechanical arm — that’s roughly London to Ankara. And a cross-region round trip, 150 milliseconds, covers about 45,000 kilometers, which is a bit more than once all the way around the Earth (the planet’s actual circumference is about 40,075 km, so this is the one entry on the list that overshoots a clean lap by some margin).

Worth being honest about that disk seek entry specifically: nothing in a spinning hard drive travels anywhere near the speed of light. That row is a hypothetical — “if this much time were instead spent by light traveling somewhere” — included for scale, not as a literal physical claim the way the network entries are. A disk seek is a read/write head physically moving across a spinning platter, which is exactly why it’s so slow compared to everything electronic on this list.

The cross-region entry, on the other hand, isn’t hypothetical at all — it’s close to the literal truth. A round trip between two continents really is bounded by how far a signal has to physically travel, through fiber running under oceans and across countries. One more honest caveat there too: signals in real fiber-optic cable travel at roughly two-thirds the speed of light in a vacuum, not the full vacuum speed used to calculate this chart, since glass has a refractive index around 1.473. That means the actual cable behind a 150ms round trip is even longer than 45,000 km, not shorter — the comparison undersells the real distance rather than exaggerating it.

Seen this way, the entire hierarchy is a story about distance in the most literal sense possible: how far away is the thing you’re asking for, physically, right now.


Fun fact, while we’re on absurd speed differences: a hummingbird’s heart beats over 1,200 times a minute in flight4 — about 20 beats a second — and slows to somewhere around 50-180 beats a minute at night, when it drops into torpor5, a nightly hibernation that keeps it from starving before morning. Its whole body runs at two wildly different clock speeds depending on whether it’s actively doing something or just idling.


Why the jumps aren’t arbitrary

None of these gaps are accidents of engineering laziness. Each one traces back to a real physical or architectural constraint.

Start with distance. L1 sits physically closer to the core than L3 does, and electrical signals don’t move instantaneously — at these timescales, a few extra millimeters of silicon is measurable. It’s a smaller-scale version of a familiar fact: a lightning flash and its thunder reach you at different times because light and sound both take time to cross a distance, just at wildly different speeds. Inside a chip, “distance” is measured in millimeters and the traveler is an electrical signal, but the principle — nothing moves instantly, so nearer is faster — is the same one.

Then there’s a genuine trade-off in how caches are built. A cache that’s both huge and as fast as L1 isn’t a design nobody’s gotten around to yet — it’s close to a contradiction in terms. Bigger caches need more complex addressing and lookup circuitry to search through more content, and that complexity itself costs time. Speed and size pull against each other by construction, not by oversight, which is exactly why chips settle for a hierarchy of caches instead of one big fast one.

Sharing adds its own tax. L3 is slower than L2 partly because it’s shared across every core on the chip, and shared memory needs coherency protocols — bookkeeping to make sure one core doesn’t read data that another core just changed underneath it. That bookkeeping isn’t free. It’s also, not coincidentally, the same root cause behind multi-threaded code slowing down when several threads fight over the same piece of memory — same mechanism, different scale.

Network cost breaks down differently again. A round trip is rarely dominated by how long the signal takes to physically travel down the wire — it’s connection setup, a chain of routing hops in between, the remote machine actually doing its own processing, and the answer making the same journey back. Raw propagation delay is usually the smallest line item in the total, not the biggest.

Where this bites people in practice

A cache hit versus a cache miss followed by a database round trip is routinely a 1,000x to 10,000x gap. That single number is the entire reason caching exists as a whole discipline rather than a footnote in a systems textbook.

The classic “N+1 query” bug comes from the same well. A loop that looks completely ordinary in code quietly makes one network round trip per iteration, so what reads like a fast loop is actually a hundred separate trips to “the next building over,” stacked back to back and paid for one at a time.

Algorithmic complexity doesn’t tell the whole story either. A linear scan through data sitting contiguously in memory can (and probably will) beat a theoretically faster tree lookup through scattered pointers, because the scan stays near the fast end of this hierarchy the whole time, while the tree walk keeps jumping to places that might not be cached at all. Big-O describes how the work scales. It has nothing to say about how far away the data physically lives while that work happens.

Octopuses have three hearts, and blue, copper-based blood instead of red iron-based blood — copper carries oxygen less efficiently than iron, which is part of why it takes three separate pumps to keep up6. It’s nature’s own answer to a slow transport layer: if the thing carrying your data is the bottleneck, add more pumps. Mostly it’s just wild that an animal is walking around with three hearts because of a metal choice, I think there’s a system design point buried in there somewhere?

References

  1. NPR, “How The Food Industry Uses Cavitation, The Ocean’s Most Powerful Punch” — npr.org
  2. Jeff Dean / Peter Norvig, “Latency Numbers Every Programmer Should Know” — gist.github.com
  3. Yang, Wang, et al., “Dissecting Latency in the Internet’s Fiber Infrastructure” (arXiv preprint) — arxiv.org
  4. AAAS Science, “To survive frigid nights, hummingbirds cool themselves to record-low temperatures” (quoting Cornell Lab of Ornithology’s Anusha Shankar) — science.org
  5. Cornell Lab of Ornithology, All About Birds — “Black-chinned Hummingbird Overview” — allaboutbirds.org
  6. Smithsonian Ocean, “Cephalopods: Octopus, Squid, Cuttlefish, and Nautilus” — ocean.si.edu