怎样测试 JavaScript 的函数性能

旧城等待， 2023-07-25 12:57 4阅读 0赞

> 作者：Felix Gerschau
> 
> 翻译：疯狂的技术宅
> 
> 原文：https://felixgerschau.com/measuring-the-performance-of-java-script-functions
> 
> **未经允许严禁转载**

通过衡量执行某个函数所花费的时间，以“证明”某些实现比另一些实现更高效始终是一个很好的主意。这也是确保性能在进行一些修改后不受影响并找出瓶颈的好方法。

良好的性能有助于获得良好的用户体验。良好的用户体验能够留住用户。像[此研究][Link 1]所示，由于性能差的用户体验，**88％ 的在线消费者**回头的可能性较小问题。

所以重要的是能够识别代码中的瓶颈并进行评估改进。特别是在为浏览器开发 JavaScript 时，重要的是应该意识到，你编写的每一行 JavaScript 都可能会阻塞 DOM，因为它是单线程语言。

在本文中，我将解释如何测量函数的性能，以及如何从函数中获得结果。

如果你发现某些计算过于繁琐而无法在主线程上进行计算，则你甚至可以考虑将其放入服务或 Web Worker 中。我在[这篇文章][Link 2]中解释了如何传递和接收来自 Service Workers 的数据。

## Perfomance.now ##

高性能API通过其函数 `performance.now()` 提供对 [DOMHighResTimeStamp][] 的访问，该函数返回自页面加载时间（以毫秒为单位），精度最高为 **5µs**（以分数为单位）。

因此在实践中，你需要获取两个时间戳，将它们保存在变量中，然后用第一个时间戳减去删除第二个时间戳：

const t0 = performance.now();
    for (let i = 0; i < array.length; i++) 
    { 
      // some code
    }
    const t1 = performance.now();
    console.log(t1 - t0, 'milliseconds');

输出（Chrome）：

0.6350000001020817 "milliseconds"

输出（Firefox）：

1 milliseconds

在这里，我们可以看到 Firefox 中的结果与 Chrome 完全不同。这是因为从版本 60 开始，Firefox 将 performance API 的精度降低到了 2ms。你可以在本文的末尾找到有关此内容的更多信息。

performance API 提供的功能比仅返回时间戳要多得多。它可以测量**导航时间、用户时间或资源时间**。查看[本文][Link 3]，其中有更详细的说明。

但是对于我们的用例，只想测量单个函数的性能，因此时间戳就足够了。

##### 与 Date.now 有什么不同吗？ #####

现在你可能会想，嘿，我也可以用 `Date.now`。

是的，你可以，但是有缺点。

`Date.now` 以毫秒为单位返回自 Unix 元年（1970-01-01T00:00:00Z）以来经过的时间，并取决于系统时钟。这不仅意味着它**不够精确**，而且还**并非总是递增**。 WebKit 工程师（Tony Gentilcore）的解释如下：

> 也许很少被考虑到的是，基于系统时间的日期也不适合实际监视。大多数系统运行一个守护程序，该守护程序负责定期同步时间。通常每 15 至 20 分钟会把时钟调整几毫秒。以这种速度，以 10 秒间隔来说，大约 1％ 将会是不准确的。

## Console.time ##

该 API 确实好用。只需将 `console.time` 放置在要测量的代码之前，将 `console.timeEnd` 放在要测量的代码之后，即可用相同的 `string` 参数调用该函数。一个页面上最多可以同时使用 10,000 个计时器。

精度与 performance API 相同，但这又取决于浏览器。

console.time('test');
    for (let i = 0; i < array.length; i++) { 
      // some code
    }
    console.timeEnd('test');

这将会自动生成人类可读的输出，如下所示：

输出（Chrome）：

test: 0.766845703125ms

输出（Firefox）：

test: 2ms - timer ended

此处的输出仍然与 Performance API 非常相似。

`console.time` 的优点是**容易使用**，因为它不需要手动计算两个时间戳之间的差。

## 时间精度降低 ##

如果你在不同的浏览器中使用上述API来评估函数，你可能会注意到**结果会有所不同**。

这是由于浏览器试图**保护用户**免受 [timing 攻击][timing] 和[指纹][Link 4]识别，如果时间戳过于准确，黑客可以使用它来识别用户。

像 Firefox 这样的浏览器试图通过把[精度降低][DOMHighResTimeStamp]到 2ms（60版）来防止这种情况。

## 注意事项 ##

现在你已经拥有了测量 JavaScript 函数运行速度所需的工具。但是还要避免一些陷阱：

### 分而治之 ###

在筛选某些结果时发现速度很慢，但你不知道瓶颈在哪里。

你可以用上面提到的这些函数来度量代码，而不必去猜测到底史哪一部分代码慢。

首先要跟踪它，把 `console.time` 语句放在执行缓慢的代码块前后。然后评估他们不同部分的表现。如果一个比另一个慢，那就继续往下走，直到发现瓶颈为止。

这些语句之间的代码越少，则跟踪到不感兴趣的内容的可能性就越小。

### 注意输入值 ###

在实际应用中，给定函数的输入值可能会发生很大变化。如果仅针对任意随机值测量函数，那么速度并不能为我们提供任何有实用价值的数据。

要确保运行代码时使用的输入值是相同的。

### 多次运行函数 ###

假设有一个函数可以遍历数组，并对每个值进行一些计算，然后返回包含结果的数组。你想知道 `forEach` 或简单的 `for` 循环哪个更有效。

这些是函数：

然后像这样测试它们：

const x = new Array(100000).fill(Math.random());
    testForEach(x);
    testFor(x);

如果在 Firefox 中运行上述函数，你将获得类似下面的输出：

test-forEach: 27ms - timer ended
    test-for: 3ms - timer ended

看起来 forEach 比较慢，对吧？

让我们看看用相同的输入对相同的函数两次运行：

testForEach(x);
    testForEach(x);
    testFor(x);
    testFor(x);
    
    test-forEach: 13ms - timer ended
    test-forEach: 2ms - timer ended
    test-for: 1ms - timer ended
    test-for: 3ms - timer ended

如果我们第二次调用 `forEach` 测试，则其性能与 `for` 循环一样。考虑到初始值较慢，可能仍然不值得使用 `forEach`。

### …还有在多个浏览器中 ###

如果我们在 Chrome 中运行上述代码，结果会突然看起来不同：

test-forEach: 6.156005859375ms
    test-forEach: 8.01416015625ms
    test-for: 4.371337890625ms
    test-for: 4.31298828125ms

这是因为 Chrome 和 Firefox 的 JavaScript 引擎是不同的，并且性能优化的类型也不同。能够意识到这些差异是一件好事。

在这种情况下，Firefox 的优化在 `forEach` 方面做得比 Chrome 更好。

`for` 在两个引擎上的性能都更好，所以最好坚持 `for` 循环。

这是一个很好的例子，说明了为什么应该在多个引擎中进行测量。如果仅用 Chrome 进行测量，你可能会得出：`forEach` 相对于 `for` 而言还算不错这样的结论。

### 限制你的 CPU ###

请注意，你的开发机器通常比浏览你网站的普通手机要快得多。

浏览器具有一项功能，可让你限制 CPU 性能。这样的话，10 或 50 毫秒很快就会变成500毫秒。

### 衡量相对表现 ###

实际上这些结果不仅取决于你的硬件，还取决于你的 CPU 和当前 JavaScript 线程的负载。尝试在不同情况下进行测量，因为下次你重新启动计算机时，你得到的数字看起来可能会大不相同。

## 结论 ##

在本文中，我们看到了一些 JavaScript API，可以使用它们来衡量性能，以及如何在\*“真实世界”\*中使用它们。对于简单的测量，我发现用 `console.time` 更容易。

我觉得很多前端开发人员普遍没有对性能进行足够的考虑，即使这对你的收入有直接的影响。

--------------------

欢迎关注微信公众号：前端先锋，每天第一时间阅读最新技术文章。

![format_png][]

[Link 1]: http://www.mcrinc.com/Documents/Newsletters/201110_why_web_performance_matters.pdf
[Link 2]: https://felixgerschau.com/how-to-communicate-with-service-workers
[DOMHighResTimeStamp]: https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp
[Link 3]: https://blog.logrocket.com/how-to-practically-use-performance-api-to-measure-performance/
[timing]: https://en.wikipedia.org/wiki/Timing_attack
[Link 4]: https://pixelprivacy.com/resources/browser-fingerprinting/
[format_png]: /images/20230528/e7238a84a98e4b4995e313a21f578a16.png