微秒级精度性能基准测试：Performance.now()实战指南

首先需要明确一个核心概念：performance.now() 返回的是以毫秒为单位的浮点数，小数点后三位对应微秒。例如，123.456 表示 123 毫秒加上 456 微秒。它的价值在于提供了亚毫秒级的测量精度，但绝不能将其返回值直接当作纳秒或整数微秒来使用，否则数据将失去意义。

单次差值测量为何不可靠

你可能写过这样的代码：const start = performance.now(); fn(); const end = performance.now(); 看起来简单直接，但得到的结果往往充满噪声，主要原因在于：

• JIT预热：JavaScript引擎的即时编译优化需要时间，前几次执行速度会明显偏慢。
• 垃圾回收（GC）干扰：GC可能在任意时刻触发，一次回收就可能导致耗时突然增加几十毫秒。
• 系统调度影响：CPU频率动态调整、浏览器后台标签页节流（例如Chrome限制后台页面每秒最多调用100次performance.now()）都会导致计时本身出现延迟。
• 精度损失：对单次结果进行Math.round()或.toFixed(0)取整，会抹掉关键的亚毫秒级抖动，从而掩盖真实的性能瓶颈。

performance.now() 返回毫秒级浮点数，小数后三位对应微秒；单次差值易受JIT、GC、节流等干扰，应预热+批量采集+剔除极值后取P50/P90。

关键算法性能基准测试的正确步骤

可靠的性能测试不是“多跑几次取平均”，而是一套控制变量、数据清洗和环境对齐的方法：

1. 强制预热：正式测量前，先执行目标函数至少10次，不计入统计，目的是让V8等引擎完成优化编译。
2. 批量采集：运行足够多的次数（例如100到500次），每次记录原始的end - start差值（保留全部小数位），存入数组。
3. 剔除极值并分析：将采集到的耗时数据排序，丢弃首尾各10%（例如500次数据就扔掉最快和最慢的各50次），然后用剩余的数据计算P50（中位数）或P90分位数。这种方法比简单的算术平均值更能抵抗异常值的干扰。

下面是一个参考的实现片段：

function benchmark(fn, iterations = 200) {
  // 预热
  for (let i = 0; i < 10; i++) fn();
  const times = [];
  for (let i = 0; i < iterations; i++) {
    const start = performance.now();
    fn();
    const end = performance.now();
    times.push(end - start);
  }
  times.sort((a, b) => a - b);
  const trim = Math.floor(times.length * 0.1);
  const trimmed = times.slice(trim, -trim);
  return trimmed.reduce((a, b) => a + b, 0) / trimmed.length;
}

在Web Worker中使用时的注意事项

performance.now()在Web Worker中可用，但必须注意，Worker与主线程拥有各自独立的performance.timeOrigin（时间原点）。Worker的时间原点是从其创建时刻开始的，而非页面加载时刻。

这意味着：

• 避免跨上下文直接比较：在主线程打一个点，在Worker内打另一个点，然后直接相减，得到的差值是没有意义的。
• 统一基准：如果必须对比，需要将双方时间转换为相对于同一基准（例如，使用主线程的timeOrigin进行换算）。
• 更稳妥的策略：尽量在同一线程上下文内完成测量和差值计算。Web Worker更适合用于隔离CPU密集型任务本身，以避免阻塞主线程，但性能测量逻辑最好保持在同一边。
• 检查可用性：在Service Worker的初始化阶段（如`install`或`activate`事件中），performance对象可能尚未就绪，使用前务必检查typeof performance !== ‘undefined’。

生产级测试为何不应依赖 console.time()

console.time()和console.timeEnd()用起来很方便，但它们存在一些固有缺陷，不适合进行严肃的性能基准测试：

• 精度不统一：其实现依赖浏览器，在某些旧版本或特定WebView中，精度可能会退化到与Date.now()类似的级别（±15毫秒）。
• 自身开销影响：输出日志本身存在性能开销，高频调用会拖慢整体执行，反而干扰了你想要测量的逻辑。
• 数据难以处理：结果仅以字符串形式输出到控制台，无法以编程方式获取原始数据进行更深入的统计分析（如计算P90、标准差等关键指标）。

如果你需要将性能标记与浏览器DevTools的性能面板（Performance panel）对齐，以便可视化地分析函数调用与渲染帧、网络请求的关系，推荐使用performance.mark()和performance.measure()。这些API会将标记和测量记录到Performance Timeline中，可以直接在性能面板中查看。

总结

真正影响应用性能的，往往不是某个函数单次执行的绝对耗时，而是多次调用下的累积抖动、不可预测的垃圾回收触发时机，或是跨线程通信带来的开销。要捕捉到这些深层次问题，必须采用严谨的方法：保留原始的浮点数精度、进行大批量的数据采集、运用分位数统计进行分析，并严格隔离测量环境。只有这样，得到的性能数据才能真正指导优化方向。