webassembly
A few weeks ago we talked about WebAssembly and its advantages over asm.js. As promised, now it’s time to look at the performance and load times of Unity WebGL in four major browsers.
几周前，我们讨论了WebAssembly及其相对于asm.js的优势 。 如所承诺的，现在是时候在四种主要的浏览器中查看Unity WebGL的性能和加载时间。
It’s been a long time since we ran the Unity WebGL benchmark and published our findings. During this time, both Unity and the browser vendors released many new versions, added support for WebAssembly and implemented post-launch optimizations, especially during the past year or so.
自运行Unity WebGL基准测试并发布我们的发现以来已经有很长时间了 。 在此期间，Unity和浏览器供应商都发布了许多新版本，增加了对WebAssembly的支持并实施了发布后的优化，尤其是在过去的一年左右的时间内。
On the Unity side, that means many changes have gone into the engine, both new features and optimizations, as well as WebGL2.0 graphics API support and an updated emscripten.
在Unity方面，这意味着引擎已进行了许多更改，包括新功能和优化，以及WebGL2.0图形API支持和更新的emscripten 。
What to expect then? Given what we mentioned in the WebAssembly blog post, we expect Unity WebGL to perform better and load faster compared to the last time we ran the Benchmark using asm.js.
那会发生什么呢？ 鉴于我们在WebAssembly博客文章中提到的内容，与上次使用asm.js运行Benchmark相比，我们希望Unity WebGL的性能更好，加载速度更快。
这是我们运行测试的方式 (Here is how we run the tests)
We rebuilt the Benchmark project with Unity 2018.2.5f1 using the following Unity WebGL Player Settings:
我们使用以下Unity WebGL Player设置使用Unity 2018.2.5f1重建了Benchmark项目 ：
On WebAssembly, we take advantage of the automatic Heap growth feature described in the Wasm blog post, so we set the Memory Size to the minimum value. To measure asm.js we made a different build with a fixed Memory Size of 512 MB, which will be enough to run the benchmark. We changed linker target accordingly.
在WebAssembly上，我们利用了Wasm博客文章中描述的自动堆增长功能，因此我们将“内存大小”设置为最小值。 为了测量asm.js，我们使用固定的512 MB内存大小进行了另一次构建，足以运行基准测试。 我们相应地更改了链接器目标 。
We tested four major browsers: Firefox 61, Chrome 70, Safari 11.1.2 and Edge 17. These are the latest stable releases at the time of writing this post, the only exception is Chrome 70 which is due to be released next month, containing a performance regression fix. We should mention that Firefox 62 also regressed in performance compared to Firefox 61 and we reported the issue to Mozilla.
我们测试了四种主要浏览器： Firefox 61 ， Chrome 70 ， Safari 11.1.2和Edge 17 。 这些是撰写本文时的最新稳定版本，唯一的例外是Chrome 70，该版本将于下个月发布，其中包含性能回归修复程序。 值得一提的是，与Firefox 61相比，Firefox 62的性能也有所下降，我们将此问题报告给Mozilla。
Contrary to the last round of performance tests, we only tested desktop 64-bit browsers, for consistency of the results, and we used newer OS/HW:
与上一轮性能测试相反，我们仅测试了台式机64位浏览器，以确保结果的一致性，并使用了较新的OS / HW：
To run the Benchmark on your machine, use this link (or as a zip). Note that depending on the browser version and os/hw you are testing on, performance may vary. On Windows, make sure to use a 64-bit browser.
要在您的计算机上运行Benchmark，请使用此链接 (或作为zip )。 请注意，根据您所测试的浏览器版本和操作系统/硬件，性能可能会有所不同。 在Windows上，请确保使用64位浏览器。
Note that there is nothing preventing you from running the benchmark on your own mobile device (The alert box about Unity WebGL not supported on mobile devices has been disabled in this build).
请注意，没有什么阻止您在自己的移动设备上运行基准测试(此版本中已禁用有关移动设备不支持的Unity WebGL的警告框)。
加载时间 (Loading Times)
One thing that changed since last time is that since Unity 5.6, Unity WebGL generates several unityweb files (Code, Data and JS Framework) that will be downloaded on startup, or fetched from browser IndexedDB cache when loading the same content again. This works pretty much the same in both WebAssembly and asm.js, however, you can expect loading Wasm code to be faster for the simple reason that the generated Wasm code is smaller. The Benchmark project outputs 4.6 MB compressed Wasm code as opposed to 6.1 MB for the asm.js version (data file is 5.6 MB and JS Framework file is ~87 KB).
自上次以来发生的变化是，自Unity 5.6以来，Unity WebGL生成了多个unityweb文件(代码，数据和JS Framework)，这些文件将在启动时下载，或者在再次加载相同内容时从浏览器IndexedDB缓存中获取。 这在WebAssembly和asm.js中几乎相同，但是，由于生成的Wasm代码较小的简单原因，您可以期望更快地加载Wasm代码。 Benchmark项目输出4.6 MB压缩的Wasm代码，而asm.js版本则为6.1 MB(数据文件为5.6 MB，而JS Framework文件为〜87 KB)。
Since network latency can affect the results, we measured Benchmark reloads (so that code and data were already in cache), and we served the build files locally. In addition, to speed up unityweb files load from IndexedDB, we changed cacheControl setting to immutable (default is must-revalidate). Here is how you can do the same for your own project html template:
由于网络延迟会影响结果，因此我们测量了基准重载(这样代码和数据已经在缓存中)，并且我们在本地提供构建文件。 另外，为了加快从IndexedDB加载unityweb文件的速度，我们将cacheControl设置更改为不可变(默认为必须重新验证)。 这是您可以为自己的项目html模板执行的操作：
|
1
2
3
4
5
6
|
var instance = UnityLoader.instantiate("gameContainer", "%UNITY_WEBGL_BUILD_URL%", {
onProgress: UnityProgress,
Module : {
cacheControl: {"default": "immutable"},
}
}
|
|
1
2
3
4
5
6
|
var instance = UnityLoader . instantiate ( "gameContainer" , "%UNITY_WEBGL_BUILD_URL%" , {
onProgress : UnityProgress ,
Module : {
cacheControl : { "default" : "immutable" } ,
}
}
|
This technique works well combined with Name Files As Hashes setting which makes Unity generate unique filenames.
该技术与“将文件命名为哈希”设置很好地结合使用，该设置使Unity生成唯一的文件名。
WebAssembly与asm.js (WebAssembly vs asm.js)
First, we are going to look at the total amount of time it takes to get to the main screen for both WebAssembly and asm.js (lower is better):
首先，我们将查看到达WebAssembly和asm.js的主屏幕所需的总时间(越小越好)：
Findings:
发现：
深度加载时间(仅WebAssembly) (In-Depth Load Times (WebAssembly-only))
Now let’s dive into the numbers that are relevant to WebAssembly. We are going to measure:
现在，让我们深入研究与WebAssembly相关的数字。 我们将要测量：
Findings:
发现：
分层编译 (Tier-ed Compilation)
As we can see, all browsers are faster to load when using WebAssembly compared to asm.js, but where does this improvement come from?
我们可以看到，与asm.js相比，使用WebAssembly时，所有浏览器的加载速度都更快，但是这种改进来自何处呢？
This is mainly due to the fact that they implemented a tiered compilation for WebAssembly. This means that the browser will now perform a very quick compilation pass at startup, then optimize hot functions later on.
这主要是由于他们为WebAssembly实现了分层编译。 这意味着浏览器现在将在启动时执行非常快速的编译过程，然后在以后优化热功能。
Firefox shipped a tiered compiler with Firefox 58, back in January. Whereas Chrome shipped their new Liftoff compiler with Chrome 69. To give you a bit of perspective on this approach, let’s see what difference it makes in Chrome:
Firefox在一月份发布了Firefox 58 分层编译器 。 Chrome随Chrome 69一起交付了新的Liftoff编译器。为了让您对这种方法有一些了解，让我们看看它在Chrome中有什么不同：
As we can see, the increase in engine initialization time is negligible, but the speed up in WebAssembly Instantiation is massive. This is great news since load times are critical for the web!
如我们所见，引擎初始化时间的增加可以忽略不计，但是WebAssembly实例化的速度是巨大的。 这是个好消息，因为加载时间对于网络至关重要！
For more information about the tiering systems in browsers, check these blog posts:
有关浏览器中分层系统的更多信息，请查看以下博客文章：
WebKit’s Assembling WebAssembly
WebKit的组装WebAssembly
Chrome’s LiftOff
Chrome的升空
实际项目的加载时间 (Real-World Projects Load Times)
Bear in mind that the Benchmark project doesn’t use a lot of assets and uses a small number of scripts. Both code and data files are relatively small, but real-world projects might result in larger builds which will impact the end-user’s experience.
请记住，Benchmark项目不使用大量资产，而是使用少量脚本。 代码和数据文件都相对较小，但实际项目可能会导致构建量较大，从而影响最终用户的体验。
Although loading times from cache are pretty fast now, don’t forget that you should still optimize your build size, so that first load time is reasonable. There won’t be a second load if the user drops-off while your content is loaded the first time!
尽管现在从缓存加载时间非常快，但是请不要忘记您仍然应该优化构建大小，这样第一次加载时间才是合理的。 如果用户在第一次加载您的内容时下车，就不会再加载第二次！
We recommend checking the Optimizing Binary Deployment Size Unite Berlin talk, as well as the Building and running a WebGL project manual page.
我们建议您查看“ 优化二进制部署大小，统一柏林”演讲，以及“ 构建和运行WebGL项目手册”页面。
Among the things that can also affect load times are shader compilation and audio decoding, so try to minimize that. The complexity of your shaders, as well as audio assets in your build can also lead to slower loading.
着色器编译和音频解码也可能会影响加载时间，因此请尽量减少这种情况。 着色器的复杂性以及构建中的音频资产也可能导致加载速度变慢。
性能 (Performance)
As explained in the first blog post, the benchmark consists of a collection of scenes that stress different parts of the Unity engine and produces a score based on the number of iterations that can be performed in a limited amount of time.
如第一篇博客文章中所述，基准测试包括一组场景，这些场景强调Unity引擎的不同部分，并基于可在有限时间内执行的迭代次数来产生分数。
Last time, Firefox outperformed the other browsers. Let’s see what changed.
上一次，Firefox胜过其他浏览器。 让我们看看发生了什么变化。
WebAssembly与asm.js (WebAssembly vs asm.js)
Here is an overview of total scores using WebAssembly and asm.js (higher scores are better):
以下是使用WebAssembly和asm.js的总得分的概述(得分越高越好)：
分数明细(仅限WebAssembly) (Scores Breakdown (WebAssembly-only))
Now, let’s take a look a the Individual Benchmark scores (scaled so that Chrome equals to 1):
现在，让我们看一下“个人基准”得分(按比例缩放，以使Chrome等于1)：
Note that WebGL2.0, a feature we haven’t benchmarked with before, is enabled by default in the build we used. So Chrome and Firefox use WebGL2.0, whereas Edge and Safari still use WebGL1.0. Having said that, we tried to disable it so that all browsers would use the same graphics API, but that didn’t seem to affect the results.
请注意，默认情况下，在我们使用的版本中启用了WebGL2.0，这是我们之前未进行过基准测试的功能。 因此，Chrome和Firefox使用WebGL2.0，而Edge和Safari仍使用WebGL1.0。 话虽如此，我们试图禁用它，以便所有浏览器都将使用相同的图形API，但这似乎并未影响结果。
Outside of the context of a simple demo project, however, WebGL2.0 will result in reduced GC pressure and frame-rate will therefore be more stable.
但是，在简单的演示项目的上下文之外，WebGL2.0将导致GC压力降低，因此帧速率将更加稳定。
For more information about performance in Unity WebGL, please check the WebGL performance considerations page in the manual.
有关Unity WebGL中性能的更多信息，请查看手册中的WebGL性能注意事项页面。
结论 (Conclusions)
The main takeaway is that today modern browsers load faster and perform better thanks to WebAssembly and that you can expect a more consistent user experience for your web content compared to asm.js. Having said that, we still recommend that you optimize your projects and test it on different browsers and os/hw.
主要要点是，借助WebAssembly，当今的现代浏览器可以更快地加载并性能更好，并且与asm.js相比，您可以期望自己的Web内容具有更一致的用户体验。 话虽如此，我们仍然建议您优化项目并在不同的浏览器和OS / HW上对其进行测试。
In the future, we might update the benchmark project again so that it also stresses other areas, like ECS and the C# Job System as well as test with WebAssembly streaming instantiation/compilation and the upcoming multi-threading support.
将来，我们可能会再次更新基准测试项目，从而使它也重点关注其他领域，例如ECS和C＃Job System以及使用WebAssembly流式实例化/编译和即将到来的多线程支持进行测试。
We’re looking forward to hearing your feedback on the Unity WebGL Forum.
我们期待听到您对Unity WebGL论坛的反馈。
翻译自: https://blogs.unity3d.com/2018/09/17/webassembly-load-times-and-performance/
webassembly
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
