Latency Numbers Every Programmer Should Know Are Wrong

Every system design guide still quotes the same latency table: L1 half a nanosecond, main memory 100 nanoseconds, a random 4 KB SSD read 150,000 nanoseconds. I re-measured the parts of it that matter on an Apple M5 Pro running macOS 26.6.2 on 2026-09-08, with a dependent-load pointer chase for the memory hierarchy and F_NOCACHE reads for storage. Main memory came back at 107.81 nanoseconds, which is the old figure. The random SSD read came back at 834 nanoseconds, which is 180 times faster than the table says. That one row moves the advice. In the original table a random disk read cost about 1500 times a main memory read. Measured here it costs 7.8 times. The "keep it in memory" reflex was priced against a gap that has collapsed by roughly 190x. Caveats are stated on screen where they belong: this is local NVMe on an Apple SoC, not network-attached cloud storage, the network numbers are over Wi-Fi, and the age of the original table is genuinely disputed. All benchmark code is in the repo. Chapters 0:00 The number that is wrong by 180x 0:52 Whose table is this, and how old 1:44 How a dependent load is timed 2:34 Terminal: sweeping the memory hierarchy 3:35 Main memory did not move 4:31 L1 is bimodal, so I quote a range 5:23 Terminal: page cache versus raw SSD 6:27 The 180x row 7:21 The read path, repriced 8:13 What this does to your cache tier 9:02 The hops that cannot improve 9:59 Where this number does not hold 10:54 Go measure your own gap The full series, in order:    • System Design from Scratch   Both benchmarks are in the repo, so you can run them on your own box: scripts/bench_latency.c pointer-chase over the memory hierarchy scripts/bench_io.py F_NOCACHE storage reads, TCP and ICMP round trips The table being re-measured is the one popularised by Jeff Dean's Stanford talk and spread by this gist, which is headed 2012, not 2009: https://gist.github.com/jboner/2841832 #systemdesign #performance #backend