一直都很快，哦
在我之前的文章中，我讨论了 WebAssembly 如何帮助您将 C/C++ 库生态系统引入 Web。其中一个广泛使用 C/C++ 库的应用是 squoosh，这是我们的 Web 应用，它允许您使用从 C++ 编译为 WebAssembly 的各种编解码器来压缩图片。
WebAssembly 是一种低级虚拟机，可运行存储在 .wasm 文件中的字节码。该字节码具有强类型和结构，因此可以比 JavaScript 更快地针对主机系统进行编译和优化。WebAssembly 提供了一个环境来运行从一开始就考虑到了沙盒和嵌入的代码。
根据我的经验，Web 上的大多数性能问题都是由强制布局和过度绘制引起的，但有时应用需要执行一项计算开销非常大的任务，需要占用大量时间。WebAssembly 可以帮到您。
热路径
在 squoosh 中，我们编写了一个 JavaScript 函数，用于将图片缓冲区旋转 90 度的倍数。虽然 OffscreenCanvas 是实现此目标的理想选择，但它不受我们针对的目标浏览器的支持，并且 Chrome 中有点问题。
此函数遍历输入图片的每个像素，并将其复制到输出图片中的其他位置，以实现旋转。对于 4094x4096 像素的图片（1600 万像素），需要对内部代码块（我们称之为“热路径”）进行超过 1600 万次迭代。尽管迭代次数相当多，但我们测试过的浏览器中有三分之二能在 2 秒或更短的时间内完成任务。此类互动的可接受时长。
for (let d2 = d2Start; d2 >= 0 && d2 < d2Limit; d2 += d2Advance) {
for (let d1 = d1Start; d1 >= 0 && d1 < d1Limit; d1 += d1Advance) {
const in_idx = ((d1 * d1Multiplier) + (d2 * d2Multiplier));
outBuffer[i] = inBuffer[in_idx];
i += 1;
}
}
而一个浏览器则需要 8 秒以上的时间。浏览器优化 JavaScript 的方式非常复杂，并且不同的引擎针对不同的目标进行优化。有些针对原始执行进行优化，有些针对与 DOM 的交互进行优化。在此示例中，我们会遇到一个浏览器中的未优化路径。
另一方面，WebAssembly 完全围绕原始执行速度而构建。因此，如果我们想实现此类代码在各种浏览器之间的快速、可预测的性能，WebAssembly 可以派上用场。
利用 WebAssembly 实现可预测的性能
通常，JavaScript 和 WebAssembly 可以实现相同的峰值性能。但是，对于 JavaScript，只能在“快速路径”上达到此性能，并且通常很难保持在“快速路径”上。WebAssembly 提供的一个主要优势是可预测的性能，即使跨浏览器运行也是如此。严格的类型和低级别架构让编译器可以更有力地保证，这样 WebAssembly 代码只需优化一次，并且将始终使用“快速路径”。
为 WebAssembly 编写代码
以前，我们提取 C/C++ 库并将其编译为 WebAssembly，以便在网络上使用它们的功能。我们并未真正涉及库的代码，而只是编写少量 C/C++ 代码来建立浏览器与库之间的桥梁。这一次，我们的动机有所不同：我们希望从头开始编写一些 WebAssembly 代码，以便利用 WebAssembly 的优势。
WebAssembly 架构
在为 WebAssembly 编写代码时，最好多了解一些 WebAssembly 实际是什么。
要引用 WebAssembly.org 中的内容，请执行以下操作：
将一段 C 或 Rust 代码编译为 WebAssembly 时，您会获得一个包含模块声明的 .wasm 文件。此声明包含模块希望从其环境中执行的“导入”列表、此模块提供给主机的导出列表（函数、常量、内存块），当然还有所含函数的实际二进制指令。
在调查后，我才没有意识到：让 WebAssembly 成为“基于堆栈的虚拟机”的堆栈并未存储在 WebAssembly 模块使用的内存块中。该堆栈完全位于虚拟机内部，Web 开发者无法访问（通过开发者工具除外）。因此，您可以编写完全不需要任何额外内存的 WebAssembly 模块，并且仅使用虚拟机内部堆栈。
在本例中，我们需要使用一些额外的内存来允许任意访问图片的像素，并生成该图片的旋转版本。这就是 WebAssembly.Memory 的用途。
内存管理
通常，使用额外的内存后，您将需要以某种方式管理该内存。内存的哪些部分正在使用中？哪些是免费的？
例如，在 C 语言中，您可以使用 malloc(n) 函数查找 n 个连续字节的内存空间。此类函数也称为“分配器”。当然，正在使用的分配器的实现必须包含在 WebAssembly 模块中，并且会增加文件大小。这些内存管理功能的大小和性能可能会因使用的算法而相差很大，因此许多语言都提供多个实现可供选择（“dmalloc”、“emmalloc”、“wee_alloc”等）。
在本例中，在运行 WebAssembly 模块之前，我们知道输入图片的尺寸（以及输出图片的尺寸）。在这里，我们看到了机会：通常，我们会将输入图片的 RGBA 缓冲区作为参数传递给 WebAssembly 函数，并返回旋转后的图片作为返回值。要生成该返回值，我们必须使用分配器。但是，由于我们知道所需的总内存量（输入图片大小的两倍，一次用于输入，一次用于输出），因此我们可以使用 JavaScript 将输入图片放入 WebAssembly 内存，运行 WebAssembly 模块以生成第二个旋转的图片，然后使用 JavaScript 读回结果。我们完全可以在不使用任何内存管理的情况下离开！
有多种选择
如果您查看我们想要 WebAssembly-fy 的原始 JavaScript 函数，就会发现它是一个纯计算代码，不包含特定于 JavaScript 的 API。因此，将此代码移植到任何语言应该非常简单。我们评估了 3 种编译为 WebAssembly 的不同语言：C/C++、Rust 和 AssemblyScript。对于每种语言，我们唯一需要回答的问题是：如何在不使用内存管理功能的情况下访问原始内存？
C 和 Emscripten
Emscripten 是适用于 WebAssembly 目标的 C 编译器。Emscripten 的目标是直接替代知名 C 编译器（如 GCC 或 Clang），并且大多与标志兼容。这是 Emscripten 的使命的核心部分，因为它希望尽可能轻松地将现有 C 和 C++ 代码编译到 WebAssembly。
访问原始内存属于 C 代码，而指针之所以存在，原因在于：
uint8_t* ptr = (uint8_t*)0x124;
ptr[0] = 0xFF;
在这里，我们将数字 0x124 转换为指向无符号 8 位整数（或字节）的指针。这会有效地将 ptr 变量转换为以内存地址 0x124 开头的数组，我们可以像使用任何其他数组一样使用它，从而允许我们访问单个字节以进行读取和写入。在本例中，我们查看的是要重新排序的图片的 RGBA 缓冲区，以实现旋转。如需移动像素，我们实际上需要一次移动 4 个连续字节（每个通道 1 个字节：R、G、B 和 A）。为了简化操作，我们可以创建一个无符号的 32 位整数数组。按照惯例，输入图片将从地址 4 开始，输出图片在输入图片结束之后直接开始：
int bpp = 4;
int imageSize = inputWidth * inputHeight * bpp;
uint32_t* inBuffer = (uint32_t*) 4;
uint32_t* outBuffer = (uint32_t*) (inBuffer + imageSize);
for (int d2 = d2Start; d2 >= 0 && d2 < d2Limit; d2 += d2Advance) {
for (int d1 = d1Start; d1 >= 0 && d1 < d1Limit; d1 += d1Advance) {
int in_idx = ((d1 * d1Multiplier) + (d2 * d2Multiplier));
outBuffer[i] = inBuffer[in_idx];
i += 1;
}
}
将整个 JavaScript 函数移植到 C 之后，我们可以使用 emcc 编译 C 文件：
$ emcc -O3 -s ALLOW_MEMORY_GROWTH=1 -o c.js rotate.c
与往常一样，emscripten 会生成一个名为 c.js 的粘合代码文件和一个名为 c.wasm 的 wasm 模块。请注意， wasm 模块 gzip 压缩到仅约 260 字节，而粘合代码在 gzip 之后大约 3.5KB。经过一些调整后，我们得以消除粘合代码，并使用 vanilla API 实例化 WebAssembly 模块。只要您不使用 C 标准库中的任何内容，使用 Emscripten 通常就可以做到这一点。
Rust
Rust 是一种新型的现代编程语言，具有丰富的类型系统、无运行时以及可保证内存安全和线程安全的所有权模型。Rust 还支持 WebAssembly 作为核心功能，Rust 团队为 WebAssembly 生态系统贡献了大量出色的工具。
其中一款工具是 rustwasm 工作组的 wasm-pack。wasm-pack 会获取您的代码并将其转换为适合 Web 的模块，开箱即可使用 Webpack 等捆绑器。wasm-pack 是一种非常便捷的体验，但目前仅适用于 Rust。该群组正在考虑添加对其他 WebAssembly 定位语言的支持。
在 Rust 中，切片是 C 语言中的数组。就像在 C 语言中一样
我们需要创建使用起始地址的切片这违背了 Rust 强制执行的内存安全模型，因此我们必须使用 unsafe 关键字，这样我们才能编写不符合该模型的代码。
let imageSize = (inputWidth * inputHeight) as usize;
let inBuffer: &mut [u32];
let outBuffer: &mut [u32];
unsafe {
inBuffer = slice::from_raw_parts_mut::<u32>(4 as *mut u32, imageSize);
outBuffer = slice::from_raw_parts_mut::<u32>((imageSize * 4 + 4) as *mut u32, imageSize);
}
for d2 in 0..d2Limit {
for d1 in 0..d1Limit {
let in_idx = (d1Start + d1 * d1Advance) * d1Multiplier + (d2Start + d2 * d2Advance) * d2Multiplier;
outBuffer[i as usize] = inBuffer[in_idx as usize];
i += 1;
}
}
使用
$ wasm-pack build
生成一个 7.6KB wasm 模块，其中包含大约 100 个字节的粘合代码（均位于 gzip 之后）。
AssemblyScript
AssemblyScript 是一个相当年轻的项目，旨在成为 TypeScript 到 WebAssembly 编译器。不过，请务必注意，它不仅会使用任何 TypeScript。 AssemblyScript 使用的语法与 TypeScript 相同，但会自行替换掉标准库。他们的标准库对 WebAssembly 的功能进行了建模。这意味着，您不能只是编译您利用 WebAssembly 所隐藏的任何 TypeScript，但这意味着您无需学习新的编程语言即可编写 WebAssembly！
for (let d2 = d2Start; d2 >= 0 && d2 < d2Limit; d2 += d2Advance) {
for (let d1 = d1Start; d1 >= 0 && d1 < d1Limit; d1 += d1Advance) {
let in_idx = ((d1 * d1Multiplier) + (d2 * d2Multiplier));
store<u32>(offset + i * 4 + 4, load<u32>(in_idx * 4 + 4));
i += 1;
}
}
鉴于 rotate() 函数具有较小的类型 Surface，可以将此代码移植到 AssemblyScript，相当容易。函数 load<T>(ptr:
usize) 和 store<T>(ptr: usize, value: T) 由 AssemblyScript 提供，用于访问原始内存。如需编译我们的 AssemblyScript 文件，我们只需安装 AssemblyScript/assemblyscript npm 软件包并运行即可
$ asc rotate.ts -b assemblyscript.wasm --validate -O3
AssemblyScript 将为我们提供一个大约 300 字节的 wasm 模块和没有粘合代码。 该模块仅适用于原版 WebAssembly API。
WebAssembly 取证
与另外两种语言相比，Rust 的 7.6KB 大得惊人。WebAssembly 生态系统中有一些工具可以帮助您分析 WebAssembly 文件（无论是使用何种语言创建的）并告诉您所发生的情况，并帮助您改善自己的情况。
树枝
Twiggy 是 Rust 的 WebAssembly 团队的另一个工具，可以从 WebAssembly 模块中提取大量富有洞见的数据。该工具并非特定于 Rust，可让您检查模块的调用图等内容，确定未使用或多余的部分，并找出哪些部分占了模块总文件大小的比例。后者可以通过 Twiggy 的 top 命令完成：
$ twiggy top rotate_bg.wasm
在本例中，我们可以看到，大多数文件大小都源于分配器。令人惊讶的是，我们的代码并没有使用动态分配。另一个重要因素是“函数名称”子部分。
Wasm 片
wasm-strip 是 WebAssembly 二进制工具包中的工具，简称 wabt。它包含一些工具，可让您检查和操控 WebAssembly 模块。wasm2wat 是一种反汇编程序，可将二进制 Wasm 模块转换为人类可读的格式。Wabt 还包含 wat2wasm，可让您将人类可读的格式重新转换为二进制 wasm 模块。虽然我们确实使用了这两个补充工具来检查 WebAssembly 文件，但我们发现 wasm-strip 最有用。wasm-strip 会从 WebAssembly 模块中移除不必要的部分和元数据：
$ wasm-strip rotate_bg.wasm
这会将 Rust 模块的文件大小从 7.5KB 减少到 6.6KB（在 gzip 之后）。
wasm-opt
wasm-opt 是 Binaryen 中的工具。它接受 WebAssembly 模块，并尝试仅根据字节码来优化该模块的大小和性能。有些工具（如 Emscripten）已运行此工具，有些工具则不会。使用这些工具通常可以尝试节省一些额外的字节。
wasm-opt -O3 -o rotate_bg_opt.wasm rotate_bg.wasm
借助 wasm-opt，我们可以再缩减一些字节，从而在 gzip 之后总共 6.2KB。
#！[no_std]
经过一些咨询和研究后，我们使用 #![no_std] 功能重新编写了 Rust 代码，而不使用 Rust 的标准库。这也会完全停用动态内存分配，从而从模块中移除分配器代码。使用以下内容编译此 Rust 文件
$ rustc --target=wasm32-unknown-unknown -C opt-level=3 -o rust.wasm rotate.rs
在 wasm-opt、wasm-strip 和 gzip 之后，生成了 1.6KB wasm 模块。虽然它仍然比 C 和 AssemblyScript 生成的模块大，但也足以被视为轻量级模块。
性能
在我们根据文件大小下结论之前，我们继续优化性能，而非文件大小。那么我们如何衡量性能呢？结果是什么呢？
如何进行基准化分析
尽管 WebAssembly 是一种低级字节码格式，但仍然需要通过编译器发送它，以生成主机专用的机器码。和 JavaScript 一样 编译器分为多个阶段运行简而言之：第一阶段的编译速度要快得多，但往往会生成较慢的代码。模块开始运行后，浏览器会观察到哪些部分经常使用，并通过更优化但速度更慢的编译器发送这些部分。
我们的用例很有趣，因为用于旋转图片的代码只会使用一次，也可能会使用两次。因此，在绝大多数情况下，我们永远无法享受到优化编译器的好处。在进行基准化分析时，请务必注意这一点。在一个循环中运行 10000 次 WebAssembly 模块会产生不切实际的结果。为了获得实际数字，我们应该运行一次模块，并根据该次运行的数字做出决策。
效果对比
这两个图表是对同一数据的不同视图。第一个图是按浏览器进行比较的图，第二个图是按所使用的语言进行比较。请注意，我选择了对数时间刻度。此外，除了一个浏览器不能在同一台机器上运行之外，所有基准测试都必须使用相同的 1600 万像素测试图片和同一台主机。
如果不过度分析这些图表，很明显，我们解决了最初的性能问题：所有 WebAssembly 模块都在大约 500 毫秒或更短的时间内运行。这印证了我们在最初的布局：WebAssembly 可为您提供可预测的性能。无论我们选择哪种语言，浏览器和语言之间的差异都很小。确切地说：JavaScript 在所有浏览器上的标准差大约为 400 毫秒，而我们的所有 WebAssembly 模块在所有浏览器上的标准差大约为 80 毫秒。
有效时间
另一个指标是我们必须投入的精力来创建 WebAssembly 模块并将其集成到 squoosh 中。很难分配数值，因此我不打算创建任何图表，但我想说明以下几点：
AssemblyScript 能够顺畅运行。它不仅可让您使用 TypeScript 编写 WebAssembly，让我的同事非常轻松地进行代码审核，还可生成无粘合的 WebAssembly 模块，这些模块非常小，性能良好。TypeScript 生态系统中的工具（如 Prettier 和 tslint）或许可以直接发挥作用。
将 Rust 与 wasm-pack 结合使用也非常方便，但在较大的 WebAssembly 项目中，更需要绑定和内存管理。为了获得具有竞争力的文件大小，我们不得不偏离 Happy-path 的路径。
C 和 Emscripten 开箱就创建了一个非常小且性能非常高的 WebAssembly 模块，但没有勇气开始使用粘合代码并将其缩减为必要的大小，最终使得总大小（WebAssembly 模块 + 粘合代码）变得非常大。
总结
因此，如果您具有 JS 热路径，并希望使其与 WebAssembly 更快速或更一致，则应使用哪种语言。一如既往的性能问题，答案是：这要视情况而定。那么，我们发了些什么呢？
从我们使用的不同语言的模块大小 / 性能权衡方面进行比较，最佳选择似乎是 C 或 AssemblyScript。我们决定推出 Rust有多种原因会导致这一决定：目前为止，Squoosh 中提供的所有编解码器都是使用 Emscripten 编译的。我们希望拓展我们对 WebAssembly 生态系统的了解，并在生产环境中使用另一种语言。AssemblyScript 是一种强大的替代方案，但项目相对年轻，编译器不如 Rust 编译器成熟。
虽然在散点图中，Rust 与其他语言之间的文件大小差异看起来非常大，但实际上并不是什么大问题：即使是通过 2G 加载，加载 500B 或 1.6KB 所需的时间也不到 1/10 秒。Rust 有望尽快缩小模块大小方面的差距。
就运行时性能而言，Rust 在不同浏览器中的平均速度比 AssemblyScript 更快。尤其是在较大的项目上，Rust 更有可能生成更快的代码，而无需手动优化代码。但这不会妨碍您使用最熟悉的功能。
话虽如此，但 AssemblyScript 是一个很棒的发现。它让 Web 开发者无需学习新语言即可生成 WebAssembly 模块。AssemblyScript 团队的响应速度非常快，并且正在积极改进他们的工具链。我们日后一定会关注 AssemblyScript。
更新：Rust
在发布这篇文章后，Rust 团队的 Nick Fitzgerald 向我们介绍了他们非常优秀的《Rust Wasm》一书，其中包含一个关于优化文件大小的部分。按照其中的说明（最值得注意的是启用链接时优化和手动紧急处理），我们可以编写“常规”Rust 代码并恢复使用 Cargo（Rust 的 npm），而不会使文件大小增大。Rust 模块在 gzip 之后最终的大小为 370B。如需了解详情，请查看我在 Squoosh 上打开的 PR。
特别感谢 Ashley Williams、Steve Klabnik、Nick Fitzgerald 和 Max Graey 在这一历程中给予的大力帮助。