一句话：首次揭示函数内联优化在 WebAssembly 中反而拖慢运行时性能的现象，并定位其成因于编译器对执行环境的错误假设。
WebAssembly 是 C、C++、Rust 等语言的编译目标，其工具链（如基于 LLVM 的 Emscripten 与 Binaryen）在实现优化时往往隐含假设本地应用与 WebAssembly 应用的执行环境相同，却忽略了 WebAssembly 流水线中还存在浏览器编译器这一环节。这种错误假设会误导函数内联优化，使得应用内联后生成的 WebAssembly 模块反而运行更慢。本文首次系统研究函数内联对 WebAssembly 运行时性能的反直觉影响：作者检视了 Emscripten C/C++-到-WebAssembly 编译器中所用 LLVM 与 Binaryen 的内联优化 pass，并在来自 LLVM 测试套件的 127 个 C/C++ 样例上进行评估。结果显示有 66 个样例因函数内联而出现反直觉的性能退化，典型情况是把热函数内联进长时间运行的函数中。作者希望这些发现能推动后续工作，在修订既有优化时充分考虑 WebAssembly 执行环境的独特特性。
The WebAssembly standard defines a bytecode format serving as a compilation target for languages such as C, C++, and Rust. WebAssembly compilers are built on top of existing compiler infrastructures such as LLVM and newly developed compiler toolchains such as Binaryen, handling various new features of the WebAssembly language. However, we observe that both these new and existing infrastructures implicitly assume that the execution environments of native and WebAssembly applications are the same, ignoring the presence of browser compilers in the WebAssembly pipeline. This incorrect assumption often misguides function inlining optimizations, resulting in a slower WebAssembly module when function inlining is applied. This paper is the first to investigate the counterintuitive impacts of function inlining on WebAssembly runtime performance. We inspect the inlining optimization passes of the LLVM and Binaryen infrastructures used in the Emscripten C/C++-to-WebAssembly compiler. Our investigation on 127 C/C++ samples from the LLVM test suite shows that 66 samples exhibit counterintuitive behavior due to function inlining, particularly from inlining hot functions into long-running functions. We hope our findings motivate further work on revising existing optimizations with the unique characteristics of WebAssembly environments in mind.