以毫秒为单位进行基准测试

matklad 新闻
benchmarking performance micro-benchmarks developer-tools rust engineering-practice blog-post

摘要

一篇风格类似 Matthias Endler（matklad）的博客文章，主张微基准测试应调整到运行约 300 毫秒——足够快以便快速迭代，又足够慢以避免启动开销并让人对速度有直观感受——其目标是让基准测试提供决策直觉，而非精确测量。

<header> <h1>以毫秒为单位进行基准测试</h1> <time class="meta" datetime="2026-10-05">2026年10月5日</time> </header> <p>一个微基准测试应该运行多久？我的经验法则是调整输入规模，直到基准测试耗时约 300 毫秒，原因如下：</p> <ul> <li> 毫秒是取值范围从 1 到 999 的整数。精度足够发现哪怕微小的提升，且便于肉眼扫描。无需使用不同单位或浮点数（对比一下 <code>1.31s</code> 与 <code>239ms</code>）。 </li> <li> 任何比方说 <code>10ms</code> 还快的测试，都有被固定成本（例如解释器启动）扭曲的风险。对计算机而言几百毫秒就是永恒，通常足以让一次性开销变得无关紧要，而无需采用更花哨（=更不稳健）的技术来显式处理它们。 </li> <li> 对人来说，几百毫秒既快，又能被感知。把数值推到人类可感知的范围内，使我能够运用自己对时间和速度的直观感受，而不必完全依赖数字感。看着一个之前卡顿的 CLI 命令经过优化变成“瞬时”响应，实在是一种纯粹的乐趣。 </li> <li> 但超过一秒的测试会让基准测试的<em>迭代</em>变得不必要地缓慢。连续运行 10 次基准测试以观察波动，应该很快才对！</li> </ul> <p>这里即将明确提出的假设是：基准测试的目的与其说是对性能的精确测量，不如说是为作者提供足够的直觉，以做出正确的决策。</p>
查看原文
查看缓存全文

缓存时间: 2026/10/06 03:03

# 以毫秒为单位进行基准测试 来源：https://matklad.github.io/2026/10/05/benchmark-milliseconds.html 2026年10月5日 一个微基准测试应该运行多久？我的经验法则是：调整输入大小，直到基准测试大约耗时 300ms 为止，理由如下： - 毫秒是 1 到 999 之间的整数。精度足够高，连微小的改进都能看出来，而且方便肉眼扫读。不需要换用不同的单位或浮点数（比如对比 `1.31s` 和 `239ms`）。 - 任何比比如说 `10ms` 更快的东西，都有被固定开销（例如解释器启动）扭曲的风险。几百毫秒对计算机来说就是永恒，通常足以让一次性开销变得无关紧要，而无需使用更花哨（＝更不健壮）的技巧来显式地扣除它们。 - 对人类而言，几百毫秒很快，但依然可感。把数字推进到人类可感知的范围内，让我能利用自己对时间和速度的直觉，而不是完全依赖数字计算能力。看着某个原本卡顿的 CLI 命令因为优化工作而变得“瞬间完成”，本身就是一种纯粹的乐趣。 - 但超过一秒就太慢了，*迭代*基准测试的速度会被拖累。连续运行 10 次基准测试来肉眼观察方差，应该很快才对！ 这里即将明确写出的假设是：基准测试的目的与其说是精确测量性能，不如说是为作者提供足够的直觉，以便做出正确的决策。

相似文章

为基准测试优化服务器

Lobsters Hottest

本文提供了逐步指南，介绍如何优化服务器以进行基准测试，旨在减少运行间噪音并确保测量可重复性，涉及硬件检查和核心固定等技术。

200毫秒

Hacker News Top

讨论200毫秒作为响应时间的关键阈值，强调其在技术系统中感知性能和用户体验中的作用。