每个程序员都应该知道的延迟数字
总体反响
- 许多人觉得这个可视化概念上很有趣，也很美观。
- 很大一部分评论说这个页面很难用，甚至无法使用，尤其是在手机和平板上。
- 也有不少人更喜欢更早、更简单的同一组延迟数据呈现方式（纯文本、表格，或者早先的交互式网站）。
UI / UX 与交互
- 主要抱怨：
- 竖排/横向文字读起来不舒服，而且常常会被浮动 UI 或浏览器界面遮挡。
- 柱条在点按时会不可预测地变短或变长；重复点击不是幂等的，感觉“失控”。
- 在很多设备上（iOS Safari、Android、Firefox mobile、iPad、4K 显示器），标签或柱条底部会被隐藏或裁切。
- 用户常常无法同时看到标签和数值，削弱了比较的能力。
- 使用说明很容易被忽略；“点击柱条上方/下方以重新缩放”的心智模型并不清晰。
- 有些人喜欢在理解之后那种有点俏皮的“重新缩放柱条”交互，但也表示它更重形式而非功能。
- 建议的改进包括：
- 横向柱状图、对数刻度静态图，或简单表格。
- 将文字放在柱条外部，或在点按时展开覆盖层。
- 自动调整大小而不是手动“点按以重新缩放”，更清晰的可操作提示（箭头、图标），以及更好的对比度/留白。
- 能够折叠/移动信息/致谢框。
数据与建模方面的担忧
- 有几项具体数字被质疑：
- 以约 44 ns 表示通过“1 Gbps”发送 1K 的说法被广泛指出不可能；对原始来源的分析表明，它实际上是在通过指数式带宽增长来建模一个更快的“commodity NIC”，而不是字面意义上的 1 Gbps 链路。
- 数据中心往返时间在数十年中保持不变，被认为值得怀疑。
- 有人认为一些磁盘和 SSD 的吞吐量/延迟数字与典型硬件相比并不准确。
- 年份滑块（+/- 年）一开始让人困惑；后来解释为这些数值是随时间外推的，而不仅仅是历史数据。
“每个程序员都应该知道的数字”的实用性
- 有些人认为这些延迟对于理解权衡关系至关重要（RAM 与磁盘、网络，以及人可感知的延迟）。
- 也有人说，大多数程序员并不做性能关键型工作，且很少需要这类数字。
- 对于用时间还是 CPU 周期来表达成本，也存在争论：
- 嵌入式/电信开发者指出，在他们的领域里，周期是标准表达方式。
- 其他人则认为，在现代多核系统中存在许多时钟域，用基于时间的、跨域比较更有意义。