toFixed()对performance.now()的行为

Question

在performance.now上使用toFixed时，它会显示一些我认为正常舍入的数字。但似乎，范围会根据平台而变化。

在chrome(v87.0.4280.66(上，它可以获得高达35位的

window.performance.now().toFixed(35); // "241989.00499999945168383419513702392578125"

在node.js(v15.2.1(上，它只有28。

performance.now().toFixed(28) // "1092.9840000011026859283447265625"

performance.timeOrigin上也存在相同的行为。我认为用performance.now()进行更准确的测量是可能的，但精度取决于硬件和软件因素，所以他们只是将精度保持在最低标准。

1. 在performance.now()上使用toFixed(100)是否更准确
2. 哪些因素影响performance.now()的范围
3. 我们可以放心地说(performance.timeOrigin + performance.now()).toFixed(12)让我们测量精确到几乎飞秒(10⁻cco⁵)或者至少比Date.now()准确得多

Answer 1

节点的performance.now实际上是：

function now() {
const hr = process.hrtime();
return hr[0] * 1000 + hr[1] / 1e6;
}

其精度为纳秒。(所以在API中，点后的26位数字是没有意义的(。这只是调用uv_hrtime(请参阅node_process_methods.cc(，它执行clock_gettime，这只是获得纳秒时间的标准方法。

在浏览器中，情况更糟——因为进行指纹识别或缓存值提取的定时攻击performance.now不太准确：

为了防止定时攻击和指纹识别，performance.now((的精度可能会根据浏览器设置进行四舍五入。

所以你真的可以依赖毫秒值。

它返回的是用铬合金夹紧的。详见time_clamper.cc。基本上它的视野局限于：

static constexpr double kResolutionSeconds = 5e-6;

有意。

正如另一个答案所指出的，.toFixed只是将数字格式化为字符串，与任何一个都无关。

---

注意：API精确到X位，这一事实并不意味着以任何方式表明第X位之后的数字为零。这只意味着你只能依靠精确到那个数字。

Answer 2

我认为说toFixed()使它更准确是错误的。

toFixed()基本上只对输入数字进行格式化。

对于performant.now()，它返回毫秒值，该值表示自时间原点以来经过的时间。

时间原点是一个标准时间，它被认为是当前文档生命周期的开始。

因此，从你的问题中，你可以想象，在不同的平台上，这个值的计算方式会有所不同。

来自mozilla.org：

• 如果当前文档是第一个加载到窗口中的文档，则时间原点是创建浏览器上下文的时间。

• 如果在卸载窗口中加载的上一个文档的过程中，显示了一个确认对话框，让用户确认是否离开上一页，则时间原点是用户确认可以导航到新页面的时间。

• 如果以上两项都不能确定时间原点，那么时间原点就是负责创建窗口当前文档的导航发生的时间。