Latency numbers every programmer should know

Original Article ↗ Hacker News Discussion ↗

An interactive remake of the classic “latency numbers every programmer should know” chart is drawing attention for both its concept and its execution. Commenters like the idea of visualizing relative costs of operations—from cache hits and memory access to SSD I/O and cross-continent round trips—but find the sideways, highly animated UI confusing, hard to read on many devices, and in places factually misleading (e.g., the 1 Gbps network figure). Many suggest simpler or logarithmic charts, clearer labels and instructions, and emphasize that if the goal is to help engineers reason about performance trade-offs, accuracy and legibility should take precedence over visual flair.

Overall reception

  • Many find the visualization conceptually interesting and visually appealing.
  • A large portion of comments say the page is hard or impossible to use, especially on mobile and tablets.
  • Several prefer earlier, simpler representations of the same latency data (plain text, table, or the earlier interactive site).

UI / UX and Interaction

  • Major complaints:
    • Vertical/sideways text is uncomfortable to read and often obscured by floating UI or browser chrome.
    • Bars shrink or grow unpredictably when tapped; repeated clicks are non-idempotent and feel “out of control.”
    • On many devices (iOS Safari, Android, Firefox mobile, iPad, 4K monitors) labels or bottoms of bars are hidden or cropped.
    • Users often can’t see both label and numeric value at the same time, undermining comparison.
    • Instructions are easy to miss; the mental model of “click above/below bar to rescale” is unclear.
  • Some like the playful “rescaling bars” interaction once understood, but say it prioritizes form over function.
  • Suggested improvements include:
    • Horizontal bars, log-scale static plots, or a simple table.
    • Text outside bars or expanding overlays on tap.
    • Auto-resizing instead of manual “tap to rescale,” clearer affordances (arrows, icons), and better contrast/padding.
    • Ability to collapse/move the info/credits box.

Data and Modeling Concerns

  • Several question specific numbers:
    • Sending 1K over “1 Gbps” given as ~44 ns is widely called out as impossible; analysis of the original source suggests it actually models a much faster “commodity NIC” via exponential bandwidth growth, not a literal 1 Gbps link.
    • Datacenter round-trip time being constant over decades is viewed as doubtful.
    • Some disk and SSD throughput/latency numbers are argued to be off compared to typical hardware.
  • The year slider (+/– year) is initially confusing; it’s clarified that values are extrapolated over time, not just historical.

Usefulness of “numbers every programmer should know”

  • Some argue these latencies are essential for understanding trade-offs (RAM vs disk vs network, human-perceived delays).
  • Others say most programmers don’t do performance-critical work and rarely need such numbers.
  • There is debate over expressing costs in time vs CPU cycles:
    • Embedded/telecom developers note cycles are standard in their world.
    • Others argue that on modern multicore systems with many clock domains, time-based, cross-domain comparisons are more meaningful.