Web Worker 通信性能研究:通过多线程改进 Web 应用性能

Surma 是谷歌的 Web 布道师,最近发布了一项有关 postMessage 的性能 研究结果 。postMessage 是 Web Worker 的通信方式。Surma 的结论是,虽然 postMessage 会带来一些开销,但如果有效载荷低于给定的开销预算,那么将非 UI 任务移出主线线可能会提高总体性能。

超过一半的互联网接入来自手机或平板电脑,而低端多核移动设备的市场份额一直在增加,Web 应用程序开发人员必须确保应用程序在低配置的环境中(如慢 CPU、GPU 或小内存)也能具有高性能。

在这种情况下,使用多线程的 Web Worker 可以将与计算相关的负载从主执行线程中隔离出来。最终的性能是在原生多核心架构上并行化任务(如果可用)所带来的好处加上与线程间通信开销相关的成本的总和。对于 Web 应用程序来说,主要的通信开销是使用 postMessage 方法在主 UI 线程和 Web Worker 之间进行通信。

由于一些开发人员不愿使用 Web Worker, Surma 对 postMessage 的性能做了一些说明。Surma 解释了他的研究背后的缘由:

人们不会考虑使用 Web Worker,是因为他们担心 postMessage()的性能,所以这是值得研究的一件事情。

该研究包括两个基准。第一个基准测试分析了在线程之间发送消息所需的时间,并显示了它与所发送的对象的复杂性之间的正相关关系。

第一个基准测试分别在 2018 款 MacBook Pro 上的 Firefox、Safari 和 Chrome 上运行,在 Pixel 3XL 的 Chrome 上运行,在诺基亚 2 的 Chrome 上运行。对象复杂度是指表示对象的 JSON 树的深度(树的层次)和宽度(属性的数量)的组合。

第二个基准测试证实了与 JSON.stringify() 返回的字符串长度的强正相关关系,不过带有一些警告。Surma 解释说:

我认为这种相关性足够强,我们可以从中得出一个法则:对象的字符串化 JSON 表示与它的传输时间大致成正比。但更重要的是,这种相关性只适用于大对象,我说的大对象是指超过 100KB 的对象。虽然这种相关性在数学上是成立的,但这种差异对于较小的有效载荷来说更为明显。

Surma 根据 响应动画空闲加载 (RAIL)指南给出了“慢”的定义,并对涉及 JS 驱动动画的上下文(显示下一帧的预算为 16ms)和不涉及上下文(响应用户交互的预算为 100ms)的情况进行了区分。

Surma 总结道:

即使在最慢的设备上,你也可以使用 postMessage() 发送 100KB 的对象,并保持在 100ms 的响应预算之内。如果有 JS 驱动的动画,有效载荷达到 10KB 是没有问题的。对于大多数应用程序来说,这应该足够了。使用 postMessage() 确实有一定的代价,但不至于会导致脱离主线程架构变得不可用。

对于 postMessage 成本超过在多个线程上运行任务的好处的情况,Surma 提供了 替代方案 ,比如通过使用分块技术或 WebAssembly 来提升性能。

完整的研究结果 可以在 Surma 的博客上找到,其中包含了数据、可视化演示和图表。

原文链接:

Improving Webapp Performance With Multi-Threading: A Study of Web Workers’ Communication Overhead

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章