Notifications
Article
WebAssembly基准测试:加载时间和性能
Published 2 months ago
101
0
我们在《Unity 2018.2正式支持WebAssembly》中介绍了WebAssembly及其优于asm.js的地方。本文将介绍Unity WebGL在四大主流浏览器中的性能和加载时间。
自从2015年底,我们运行Unity WebGL基准测试并发表测试结果以来,现在Unity和浏览器厂商都发布了很多新版本,增加了对WebAssembly的支持并实现了启动后优化。
对于Unity,那意味着引擎迎来了很多变化,包括新功能和优化,以及WebGL2.0图形API支持和更新后的emscripten。
新变化的效果将会如何呢?根据我们在上一篇文章《Unity 2018.2正式支持WebAssembly》中所谈的,相对于上次使用asm.js得到的基准测试结果,我们希望Unity WebGL能够得到更好的执行效果和更快的加载时间。

测试方法

我们使用Unity 2018.2.5f1基于以下Unity WebGL Player设置重构了Benchmark项目。
对于WebAssembly,我们使用了前一篇文章介绍的自动堆增长功能,所以我们将Memory Size设为最小值。为了测试asm.js,我们制作了另一个版本,Memory Size设为512MB,该值足以运行基准测试。我们还相应地修改了链接目标。
我们测试了四大主流浏览器:Firefox 61、Chrome 70、Safari 11.1.2和Edge 17。这些大都是撰写本文时各个浏览器的最新稳定版本,Chrome 70是个例外,该版本将在下个月发布,其中包含性能回归修复。和Firefox 61相比,Firefox 62的性能有所下降,我们已向Mozilla报告了该问题。
和上一次性能测试相反,这次我们只测试64位桌面浏览器,以保证结果的一致性,我们使用了较新的系统和硬件:
  • Windows 10 - Intel Xeon W-2145,32GB RAM,NVIDIA 1080
  • MacOS 10.13.6 - 2018 MacBook Pro 15“,Radeon Pro 560X
如果你想在自己电脑上运行基准测试,请点击链接进行测试,或下载测试项目压缩包。
  • Benchmark project
http://files.unity3d.com/marcot/benchmark2018-project.zip
  • Benchmark项目测试压缩包
https://files.unity3d.com/marcot/benchmarks2018.zip

请注意:根据测试时浏览器版本和系统,硬件的不同,得到的性能结果会有所不同。请在Windows系统上使用64位浏览器。你也可以在移动设备上运行基准测试。该版本中显示Unity WebGL不支持移动设备的警告栏已被禁用。

加载时间

从Unity 5.6开始,Unity WebGL会生成多个unityweb文件,包括代码、数据和JS Framework文件,这些文件会在启动时下载,或是在加载相同内容时从浏览器的IndexedDB缓存中抓取。
这和WebAssembly与asm.js的工作方式类似,然而,因为生成的Wasm代码更小,所以加载Wasm代码的速度会更快。Benchmark项目会输出4.6 MB的压缩Wasm代码,asm.js版本则会输出6.1MB的代码,其中代码文件为5.6 MB,JS Framework文件约87KB。
由于网络延迟会影响测试结果,我们测试了Benchmark项目的重复加载结果,并在本地提供构建文件。此外,为了加快unityweb文件从IndexedDB加载的速度,我们修改cacheControl的设置为immutable。
下面代码也可以用于自己项目的HTML模板:
var instance = UnityLoader.instantiate("gameContainer", "%UNITY_WEBGL_BUILD_URL%", {
onProgress: UnityProgress,
Module : {
cacheControl: {"default": "immutable"},
}
}
该方法结合Name Files As Hashes设置后效果很好,Name Files As Hashes设置使Unity生成了独特的文件名。

1.WebAssembly vs asm.js

首先我们要了解WebAssembly和asm.js中打开主屏幕所需的时间,数值越小越好:
测试结果:
  • 在Windows和macOS上,Firefox的加载时间都非常快。
  • 在使用WebAssembly时,Chrome和Edge的加载速度都明显比asm.js更快。
  • 除了Safari,所有浏览器加载WebAssembly的速度都比asm.js快。

2.深入研究加载时间(仅限WebAssembly)

现在了解一下WebAssembly的相关参数。我们将要测试:
  • WebAssembly实例化时间:WebAssembly的编译和实例化过程所花的时间。
  • 引擎初始化时间:Unity引擎初始化和加载首个场景所花的时间。
  • 进入屏幕时间:渲染第一帧所花的时间。
  • 交互时间:加载和取得稳定帧率所花的时间。
我们重载了Benchmark项目,以从IndexedDB缓存抓取unityweb文件:
测试结果:
  • Firefox在Windows和Mac上的总体速度都是最快的。
  • Edge的执行效果很好。它可以很快的编译Wasm,甚至比Firefox更快,但是在初始化Unity时的速度较慢。

3.分层编译

根据观察,和asm.js相比,所有浏览器加载WebAssembly的速度都更快,但是为什么会得到该结果呢?
这主要因为开发人员为WebAssembly实现了分层编译。这意味着浏览器会在启动时执行快速编译通道,然后优化主要功能。
Firefox于今年1月推出了带有分层编译器的Firefox 58。Chrome在Chrome 69中推出了Litoff编译器。为了让你了解该编译方法的效果,下面是Chrome中启用和禁用Litoff编译器产生的不同结果:
我们可以看到,引擎初始化时间没太大区别,但是WebAssembly实例化的速度却大幅提高。这是很好的消息,因为加载时间对于Web来说至关重要。

4.实际项目的加载时间

Benchmark项目没使用太多资源,而是使用了少量脚本。代码和数据文件都比较小,但是实际项目会有更大的版本文件,这将影响最终用户的体验。
虽然目前缓存的加载时间很短,但我们仍要优化构建大小,以便首次加载时间更合理。如果用户在第一次加载内容时中断,就不会再有二次加载过程。
可能影响加载时间的因素还有着色器编译和音频解码,所以建议尽可能缩短这二个过程的时间。着色器的复杂度和音频资源大小都会影响加载的速度。

性能

基准测试由一系列场景组成,这些场景会测试Unity引擎的不同部分,并根据有限时间内的迭代次数得出测试分数。
上一次Firefox的表现优于其它浏览器。让我们看看这次发生了什么变化。

1.WebAssembly vs asm.js

下图是使用WebAssembly和asm.js得到的总分对比,分数越高越好:
测试结果:
  • 使用WebAssembly时,所有浏览器得到的分数都比较高。
  • 在Windows系统上,所有浏览器都得到了差不多的结果。
  • 在MacOS上,Firefox的结果优于其它浏览器。注意,即使是Firefox上asm.js的实现也比其它浏览器中WebAssembly的实现更快。
  • Safari是从WebAssembly受益最大的浏览器,因为Safari不支持asm.js优化。

2.评分分析(仅限WebAssembly)

现在查看一下各部分的基准测试评分,下图经过调整使Chrome的评分等于1:
在几乎所有基准测试场景中,Firefox都是最快的浏览器,而且在部分独立测试中也表现优秀。然而,如果使用Firefox 62进行测试的话,就不会得到那么好的结果,原因是前面所提到的性能回归问题,我们希望该问题在不久后解决。
WebGL2.0在之前没有进行过基准测试,该功能在这次的版本中默认启用。所以,Chrome和Firefox使用WebGL2.0,而Edge和Safari仍使用WebGL1.0。我们曾禁用WebGL2.0进行测试,使所有浏览器使用相同的图形API,但这样做并没有对测试结果产生什么影响。
不考虑简单演示项目的话,WebGL2.0能降低GC压力,因此帧率会更加稳定。

结语

今天的浏览器的加载速度更快,性能更好,这都得益于WebAssembly。与asm.js相比,WebAssembly将使Web内容拥有更一致的用户体验。话虽如此,我们仍建议开发者优化自己的项目,并在不同的浏览器和系统/硬件环境下进行测试。
未来我们或许还会更新基准测试项目,使它涵盖其它功能,例如:ECS和C# Job System,并测试WebAssembly流式实例化和编译过程,以及即将推出的多线程支持。
更多Unity最新功能介绍尽在Unity官方中文论坛 (UnityChina.cn)!

Unity China
379
Comments