Latency numbers every programmer should know

Original Article ↗ Hacker News Discussion ↗

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.