Latency Numbers Explorer
An interactive version of the classic "latency numbers every programmer should know." Compare the real time of an L1 cache reference, a memory read, an SSD read, a same-datacenter round trip and a cross-continent round trip — then scale them all to human time (where one CPU cycle is a second) to feel just how enormous the gaps really are.
- L1 cache reference0.5 ns
- Branch mispredict3 ns
- L2 cache reference4 ns
- Mutex lock / unlock17 ns
- Main memory reference100 ns
- Read 1 MB sequentially from memory3.0 µs
- SSD random read16 µs
- Read 1 MB from SSD49 µs
- Round trip within same datacenter500 µs
- Disk seek (HDD)3.0 ms
- Read 1 MB from disk (HDD)5.0 ms
- Round trip CA ↔ Netherlands150 ms
Order-of-magnitude figures. Switch to human scale and a same-datacenter round trip becomes about a week, a cross-continent one years — the gaps that justify caching, locality and avoiding network hops.
Everyone nods at “memory is fast, the network is slow,” but the numbers are far more extreme than intuition suggests. The classic latency table — an L1 cache reference under a nanosecond, main memory around 100 ns, an SSD read near 100 microseconds, a same-datacenter round trip about 500 microseconds, a hop between continents around 150 milliseconds — spans nine orders of magnitude. The problem is that “nanosecond” and “millisecond” both register as simply small, so the gulf between them disappears.
The fix is to stretch time. If one CPU cycle were one second, the hierarchy becomes something you can feel: main memory is a couple of minutes away, an SSD read is days, a round trip across the datacenter is about a week, and a cross-continent round trip is years. This explorer does exactly that flip — real numbers on one side, human-scaled on the other — so the distance between a cache hit and a network call stops being abstract.
That intuition is the foundation of a huge amount of system design. Every layer down the hierarchy — cache to memory to SSD to local network to another region — is roughly a thousand times slower than the one above it, so turning a memory access into a network call is not a small regression, it is a catastrophic one. This is why we cache, why we care about data locality, and why we batch or avoid remote calls. The absolute numbers drift with each hardware generation, but the ratios are stubbornly stable, which is what makes these numbers worth carrying in your head.
How it works
- Real times: L1/L2, memory, SSD, datacenter and cross-continent RTT.
- One-click scale to human time (1 cycle = 1 second).
- Makes the orders-of-magnitude gaps tangible.
- The intuition behind caching, locality and avoiding hops.
Frequently asked questions
What are "the latency numbers every programmer should know"?
A famous set of approximate timings (popularized by Jeff Dean and Peter Norvig) for common operations: an L1 cache reference is under a nanosecond, main memory is ~100 ns, an SSD read is ~100 microseconds, a same-datacenter network round trip is ~500 microseconds, a disk seek is a few milliseconds, and a round trip between continents is ~150 milliseconds. Knowing their relative scale is what lets engineers reason about where time actually goes.
Why scale them to human time?
Because nanoseconds and milliseconds are both just "small" to human intuition, which hides the enormous gaps between them. If one CPU cycle were one second, then main memory would be a couple of minutes away, an SSD read would be days, a same-datacenter round trip about a week, and a cross-continent round trip years. Stretching the numbers into human time makes the difference between a cache hit and a network call viscerally obvious.
How should these numbers change how I design systems?
They explain why caching, locality and avoiding network hops matter so much: each step down the hierarchy — cache, memory, SSD, local network, cross-region — is orders of magnitude slower than the last. A design that turns a memory access into a network round trip just made that operation roughly 1000× slower. The numbers are the intuition behind "keep hot data close" and "batch or avoid remote calls."
Are these exact?
No — they are order-of-magnitude figures, and real values shift with hardware generations (NVMe SSDs are faster than the classic SSD number, memory and caches vary by CPU). The point is not precision but the relative scale, which has stayed remarkably stable: the gaps between cache, memory, storage and network are what matter, and those ratios hold even as absolute numbers improve.