将应用的 JavaScript 中的热路径替换为 WebAssembly

Surma

速度一直很快，

在我的上一张幻灯片中， 文章，我介绍了 WebAssembly 可让您将 C/C++ 库生态系统引入 Web。一款应用 广泛利用了 C/C++ 库的 squoosh Web 应用，可让您使用 从 C++ 编译到 WebAssembly。

WebAssembly 是一种底层虚拟机，用于运行存储在 .wasm 文件中的字节码。这种字节码采用强类型和结构，因此可以比 JavaScript 更快地针对主机系统进行编译和优化。WebAssembly 提供了一个环境，可运行从一开始就考虑了沙盒化和嵌入的代码。

根据我的经验，网络上的大多数性能问题都是 但有时应用需要执行 需要大量时间才能完成的计算开销大的任务。WebAssembly 可以提供帮助 此处。

注意：出于法律方面的考虑，我不会在本文中列出任何浏览器的名称。

热路径

在 squoosh 中，我们编写了一个 JavaScript 函数。 将图片缓冲区旋转 90 度的倍数。虽然 OffscreenCanvas 非常适合此用途，但我们定位的浏览器不支持它，而且它在 Chrome 中存在一些 bug。

此函数会迭代输入图片的每个像素，并将其复制到输出图片的其他位置，以实现旋转。对于 4094px 4096 像素的图片（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，只有在“快路”上才能达到这种性能，而要想一直走在“快路”上，通常很难。Google Cloud WebAssembly 提供可预测的性能，即使跨浏览器也是如此。严格的类型和低级架构使编译器能够做出更强的保证，因此 WebAssembly 代码只需优化一次，并且将始终使用“快速路径”。

为 WebAssembly 编写代码

以前，我们会将 C/C++ 库编译为 WebAssembly，以便在 Web 上使用其功能。我们并没有涉及任何库的代码， 只是编写了少量的 C/C++ 代码，在浏览器与 Google Cloud 之间 和库这一次，我们的动机不一样了： 使用 WebAssembly 方法创建代码 WebAssembly 的优势

WebAssembly 架构

在为 WebAssembly 编写代码时，不妨详细了解一下 WebAssembly 的实际含义。

如需引用 WebAssembly.org，请使用以下格式：

注意：WebAssembly（缩写为 Wasm）是一种二进制指令格式， 基于堆栈的虚拟机Wasm 是作为一种可移植的目标 可以对 C/C++/Rust 等高级语言进行编译， 适用于客户端和服务器应用的 Web 应用。

将一段 C 或 Rust 代码编译为 WebAssembly 时，您会看到一个 .wasm 文件。此声明包含 "导入"模块期望从其环境中获取内容、此 模块（函数、常量、内存块）可供主机使用，并且 当然是其中包含函数的实际二进制指令。

在深入了解之前，我才发现一个堆栈 WebAssembly 是一个“基于堆栈的虚拟机”未存储在 WebAssembly 模块使用的内存该堆栈完全位于虚拟机内部，Web 开发者无法访问（除非通过开发者工具）。因此，您可以编写完全不需要任何额外内存且仅使用虚拟机内部堆栈的 WebAssembly 模块。

注意：Emscripten 等编译器仍使用 WebAssembly 内存来实现自己的堆栈。这样做是为了让您能够通过 C 语言中的指针等结构访问堆栈上的任何位置的值，而虚拟机内部堆栈不允许这样做。因此，有点令人困惑的是，当您通过 WebAssembly 运行 C 语言时，系统会使用 两个堆栈！

在本例中，我们需要使用一些额外的内存来允许任意访问 并生成该图像的旋转版本。这是 WebAssembly.Memory的用途。

内存管理

通常，一旦使用了额外的内存，就会发现 管理这些记忆内存的哪些部分正在使用？哪些应用是免费的？ 例如，在 C 中，您可以使用 malloc(n) 函数查找连续 n 个字节的内存空间。此类函数也称为“分配器”。 当然，您必须在 WebAssembly 模块中添加所用分配器的实现，这会增加文件大小。此大小和性能 而这些内存管理功能在内存管理方面可能会存在很大差异，具体取决于 所用的算法，正因如此，许多语言都提供 进行选择（“dmalloc”、“emmalloc”、“wee_alloc”等）。

在本例中，我们知道输入图片的尺寸（因此也知道 输出图像尺寸），然后再运行 WebAssembly 模块。我们发现了一个机会：传统上，我们会将输入图片的 RGBA 缓冲区作为参数传递给 WebAssembly 函数，并将旋转后的图片作为返回值返回。要生成该返回值，我们必须使用分配器。 但由于我们知道所需的内存总量（是输入大小的两倍） 一次用于输入，一次用于输出），我们就可以将输入图片放入 WebAssembly 内存使用 JavaScript，请运行 WebAssembly 模块以生成 第 2 张旋转的图片，然后使用 JavaScript 读回结果。我们可以 完全不需要使用任何内存管理！

品类众多，令人爱不释手

如果您之前查看过原始 JavaScript 函数 可以看到，这是一个纯计算 不含 JavaScript 专用 API 的代码。因此，它应该相当直截了当 可将此代码移植到任何语言。我们评估了 3 种可编译为 WebAssembly 的不同语言：C/C++、Rust 和 AssemblyScript。唯一的问题 我们需要回答的问题是： 如何访问原始内存 而不使用内存管理功能？

注意：我跳过了部分，并着重介绍 热路径和内存访问每个示例的完整版本以及 您可以在 gist。

C 和 Emscripten

Emscripten 是 WebAssembly 目标平台的 C 编译器。Emscripten 的目标是 函数直接取代 GCC 或 Clang 等知名 C 编译器 并且大体上与标志兼容这是 Emscripten 的任务的核心所在。 因为它希望将现有 C 和 C++ 代码编译到 WebAssembly 中变得像

访问原始内存是 C 语言的本质，指针之所以存在，正是因为这个原因：

uint8_t* ptr = (uint8_t*)0x124;
ptr[0] = 0xFF;

在这里，我们将数字 0x124 转换为指向无符号 8 位整数（或字节）的指针。这样可以有效地将 ptr 变量转换为数组 从内存地址 0x124 开始，我们可以像使用任何其他数组一样使用， 允许我们访问各个字节以进行读取和写入。在本例中，我们将研究一张图片的 RGBA 缓冲区，并希望对其进行重新排序以实现旋转。如需移动一个像素，我们实际上需要一次移动 4 个连续的字节（每个通道一个字节：R、G、B 和 A）。为简化起见，我们可以创建一个由 32 位无符号整数组成的数组。按照惯例，我们的输入图片将 我们的输出图像将紧跟在输入图像之后 结束时间：

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;
    }
}

注意：我们之所以选择从地址 4（而非 0）开始，是因为地址 0 在许多语言中都有特殊含义：它是可怕的 null 指针。虽然 从技术上讲，0 是完全有效的地址，许多语言都不会将 0 视为有效的地址 并抛出异常或直接进入未定义状态， 行为。

将整个 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。我们稍作调整，就成功放弃了 粘合代码，并使用原版 API 实例化 WebAssembly 模块。 通常，只要您不使用 C 标准库中的任何内容，就可以使用 Emscripten 实现此目的。

注意：我们正在与 Emscripten 团队合作，旨在减小或 有时甚至不存在。

Rust

注意：自本文发布以来，我们对如何针对 WebAssembly 优化 Rust 有了更多了解。请参阅本文末尾的更新部分。

Rust 是一种新型的现代编程语言，具有丰富的类型系统，无需运行时 以及可保证内存安全和线程安全的所有权模型。锈红色 也支持将 WebAssembly 作为核心功能，Rust 团队 为 WebAssembly 生态系统贡献了大量出色的工具。

其中一种工具是 wasm-pack 与 rustwasm 工作组联系。wasm-pack 可接受您的代码并将其转换为适合网络使用的模块， 支持开箱即用。wasm-pack 非常方便，但目前仅适用于 Rust。该群组是 正在考虑增加对其他以 WebAssembly 为目标的语言的支持。

在 Rust 中，slice 相当于 C 中的数组。就像使用 C 语言一样，我们需要创建 使用起始地址的切片。这与内存安全模型背道而驰 所以我们必须使用 unsafe 关键字， 允许我们编写不符合该模式的代码。

注意：这不是最佳做法。根据我们的经验， 使用 emscripten 中的 embind 等绑定机制 或 wasm-bindgen - 。

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;
    }
}

使用以下代码编译 Rust 文件：

$ wasm-pack build

会生成一个 7.6KB wasm 模块，其中包含大约 100 字节的粘合代码（均在 gzip 之后）。

AssemblyScript

AssemblyScript是 旨在成为 TypeScript-to-WebAssembly 编译器的年轻项目。时间是 但需要注意的是，它不会仅使用任何 TypeScript。 AssemblyScript 使用的语法与 TypeScript 相同，但前者与后者中的 自己的资源库其标准库对 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() 函数的类型接口很小，因此将此代码移植到 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-Strip

wasm-strip 是 WebAssembly Binary Toolkit（简称 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]

经过一番咨询和研究，我们重新编写了 Rust 代码，但没有使用 Rust 的标准库，使用 #![no_std] 功能。这也会完全停用动态内存分配 分配器代码。编译此 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 生成的模块大， 可以认为是轻量级

注意：根据 Twiggy 的说法，文件大小的主要贡献者是 core::fmt，这是一个用于将数据转换为字符串的模块（类似于 C 的 printf()）。可能会触发异常的代码路径会使用它，因为它们会生成人类可读的异常消息。Rust 的 WebAssembly 团队已意识到这一点，并正在积极改进。

性能

在仅根据文件大小就得出结论之前，请注意，我们此次改进是为了优化性能，而不是文件大小。那么，我们是如何衡量绩效的？ 效果如何？

如何进行基准测试

尽管 WebAssembly 是一种低级字节码格式，但仍需要通过编译器发送，以生成特定于主机的机器码。与 JavaScript 一样 编译器会分多个阶段运行简而言之：第一阶段是 但编译速度往往较慢。模块开始运行后，浏览器会观察哪些部分被频繁使用，并通过优化程度更高但速度更慢的编译器发送这些部分。

我们的用例很有趣，因为用于旋转图片的代码将被使用一次，也许两次。因此在绝大多数情况下， 优化编译器的优势。在进行基准测试时，请务必注意这一点。在循环中运行 WebAssembly 模块 10,000 次会产生 不切实际的结果。为了得到实际数字，我们应该运行一次模块， 根据单次运行的数据做出决策。

注意：理想情况下，我们应该自动执行重新加载页面和运行模块一次，然后多次执行该过程。我们认为，只需进行几次人工运行，就可以根据这些平均值做出明智的决策。

效果对比

这两个图表是对相同数据的不同视图。在第一个图表中，我们按浏览器进行比较；在第二个图表中，我们按所用语言进行比较。请注意，我选择了对数时间尺度。值得注意的是，所有基准测试都使用了相同的 1600 万像素测试图片和相同的主机，但有一款浏览器无法在同一台机器上运行。

无需过多分析这些图表，我们就可以清楚地看到，我们解决了最初的性能问题：所有 WebAssembly 模块的运行时间均在 500 毫秒左右。这个 WebAssembly 提供可预测的 性能无论我们选择哪种语言，浏览器之间的差异 和语言最少。确切地说，JavaScript 的标准差 在所有浏览器上都约为 400 毫秒，而我们所有浏览器的标准差 WebAssembly 模块在所有浏览器中的运行时间均为 80 毫秒左右。

有效时间

另一项指标是我们为打造和集成 转换为 squoosh。很难为“努力程度”分配一个数字值，因此我不会创建任何图表，但我想指出以下几点：

AssemblyScript 可以顺畅运行。它不仅可以让你使用 TypeScript 编写 WebAssembly，使代码审核对我的同事来说非常轻松，但也 可生成无粘合的 WebAssembly 模块，这些模块非常小巧，并且 性能TypeScript 生态系统中的工具（如 prettier 和 tslint） 可能就会奏效

将 Rust 与 wasm-pack 组合使用也非常方便，但会更加出色 在更大的 WebAssembly 项目中，绑定和内存管理 所需的资源。为了实现具有竞争力的文件大小，我们不得不稍微偏离常规路径。

C 和 Emscripten 创建了一个非常小且高性能的 WebAssembly 模块 开箱即用，但缺乏勇气直接使用胶水代码并将其缩减为 最终，总大小（WebAssembly 模块 + 粘合代码）的必要性 非常大

总结

如果您有 JS 热路径并希望将其转换为 与 WebAssembly 实现更快或更一致。与性能问题一样，答案是：取决于具体情况。我们配送的是什么货物？

注意：再次提醒您，两个轴均采用对数刻度，x 轴的刻度范围为 2000 字节，而 y 轴的刻度范围为 10 秒。

比较我们使用的不同语言的模块大小/性能权衡，最佳选择似乎是 C 或 AssemblyScript。我们决定发布 Rust。那里 导致这一决定有多种原因：到目前为止，Squoosh 中搭载了所有编解码器 都是使用 Emscripten 编译的。我们希望拓展对 WebAssembly 生态系统的了解，并在生产环境中使用其他语言。AssemblyScript 是一个不错的替代方案，但该项目相对较新，编译器不如 Rust 编译器成熟。

虽然 Rust 与其他语言版本在文件大小上 在散点图中看起来相当大，但实际上并没有那么大的意义： 加载 500B 数据，即使在 2G 网络环境中加载 1.6KB 也不到 1/10 秒。Rust 有望很快缩小模块大小方面的差距。

在运行时性能方面，Rust 在各浏览器中的平均速度比 AssemblyScript 快。尤其是在大型项目中，Rust 更有可能生成运行速度更快的代码，而无需手动进行代码优化。但 您不应妨碍您选用自己最熟悉的工具。

尽管如此，AssemblyScript 还是一个了不起的发现。它允许 开发者不必学习 语言。AssemblyScript 团队响应迅速，并且积极 致力于改进其工具链。我们一定会密切关注 AssemblyScript。

更新：Rust

发布这篇文章后，Nick Fitzgerald 为我们推荐了他们优秀的《Rust Wasm》一书， 一个关于优化文件大小的部分。按照其中的说明（最值得注意的是启用链接时间优化和手动 panic 处理）操作后，我们能够编写“正常”Rust 代码，并恢复使用 Cargo（Rust 的 npm），而不会增加文件大小。Rust 模块结束 经过 gzip 处理后大小增加到 370B。如需了解详情，请查看我在 Squoosh 上开设的公关。

特别感谢 Ashley Williams、Steve Klabnik、Nick Fitzgerald 和 Max Graey，感谢他们在此旅程中提供的大力帮助。