在大多数工程认知中，将解析器从 TypeScript 改写为 Rust 并编译为 WebAssembly 意味着性能提升。然而 OpenUI 团队的真实案例呈现出完全相反的结果：将 Rust WASM 解析器回迁为 TypeScript 后，单次调用提升 2.2 至 4.6 倍，流式处理总耗时降低 2.6 至 3.3 倍。这一反直觉现象的根因并非 Rust 本身变慢，而是 WASM 与 JavaScript 之间的边界成本、JavaScript 引擎的 JIT 编译优化以及流式处理算法复杂度三个因素共同作用的结果。
边界成本何以成为主导因素
当一个 Rust 解析器通过 WASM 在浏览器中运行时，每次调用都需要经历固定的数据迁移开销。输入字符串必须从 JavaScript 堆复制到 WASM 的线性内存中，这一步骤涉及内存分配与内存拷贝操作。Rust 解析逻辑执行完毕后，结果需要序列化 —— 团队最初使用 serde_json 将结果转换为 JSON 字符串，这意味着在 WASM 内部完成序列化后，再将字符串拷贝回 JavaScript 堆，最后由 V8 的原生 JSON.parse 反序列化为 JavaScript 对象。这四个步骤 —— 输入拷贝、解析、序列化、输出拷贝与反序列化 —— 构成了一次完整的调用开销，而解析器本身的计算时间占比极低。
团队进一步尝试使用 serde-wasm-bindgen 直接返回 JavaScript 对象，期望省去 JSON 序列化的中间步骤。然而基准测试显示这一方案反而比 JSON 方案慢 9% 至 29%。原因在于 JavaScript 无法直接读取 Rust 结构体在 WASM 线性内存中的字节布局，两套运行时的内存模型完全不兼容。serde-wasm-bindgen 必须在内部递归地将 Rust 数据逐字段转换为 JavaScript 对象，这一转换过程涉及数百次细粒度的边界穿越，其累计开销远超单次 JSON 字符串的整体拷贝。简言之，一次大块数据的迁移成本低于数百次小块数据的迁移，即使后者发生在单次函数调用内部。
V8 JIT 优化的隐性加速
TypeScript 解析器能够在纯 JavaScript 环境中获得性能优势的第二项关键因素在于 V8 引擎的即时编译优化。现代 JavaScript 引擎会对热点代码路径进行深度优化，将 TypeScript 编译后的 JavaScript 代码编译为高度优化的机器码。对于解析器这类计算密集且调用频繁的工作负载，当同一段解析逻辑在流式处理中被反复执行时，V8 会将其识别为热点并触发 TurboFan 优化管道，最终生成的代码在执行效率上与原生 Rust 代码相差无几。Rust 的优势在于没有 JIT 编译的预热阶段，但解析文本字符串恰好是 JavaScript 引擎最为擅长的场景之一 —— 字符遍历、模式匹配、正则表达式等操作均被高度优化。
这并不意味着 Rust 在所有计算场景下都失去优势。关键在于区分计算类型：大规模数值计算、图像处理、视频编解码、加密运算等属于标量计算密集型任务，Rust 的原生性能优势得以保留，因为 JavaScript 引擎无法将这类操作优化到同等水平。而结构化文本解析恰恰落在 JavaScript 引擎的舒适区内 —— 字符串处理正是 V8 投入最多优化资源的领域。当原始计算速度足够快时，边际成本由边界开销主导，而非计算本身。
流式处理的算法复杂度陷阱
除边界成本与 JIT 优化外，团队在流式场景中发现了更深层的性能瓶颈。解析器在每次大语言模型输出新片段时被调用，早期实现采用朴素策略：每当新片段到达时，将已累积的所有文本重新拼接后完整解析一次。这导致 1000 字符的输出若以 20 字符为单位分 50 次到达，实际处理的总字符数达到约 25000 字符，时间复杂度为 O (N²) 级别。
团队通过引入语句级增量缓存解决了这一问题。解析器以深度为 0 的换行符作为语句分隔标记，已完成的语句被缓存其 AST 表示，不再重复解析。只有末尾仍在进行中的不完整语句需要重新解析。这一改进将流式处理的时间复杂度从 O (N²) 降至 O (N)，在 contact-form 测试用例上将总耗时从 316 微秒降至 122 微秒，在 dashboard 测试用例上从 840 微秒降至 255 微秒。值得注意的是，这一算法优化带来的收益超过了从 WASM 切换到 TypeScript 本身带来的收益，证明在性能优化中算法改进往往比语言层面的优化更具杠杆效应。
工程决策参数与监控要点
基于上述分析，面向实际工程的优化决策应考虑以下参数与监控维度。首先，边界成本阈值测定：在决定是否使用 WASM 之前，应通过火焰图或 perf 工具测定单次调用中数据迁移与序列化的占比。若边界开销占据总耗时超过 60%，则 WASM 的计算加速将被抵消，此时应优先考虑纯 JS 实现或大幅优化数据传递方式。其次，输入规模阈值：对于频繁调用且单次输入小于 500 字符的场景，WASM 的冷启动与边界成本通常难以 amortize；输入规模越大，WASM 的计算优势越容易显现。
监控层面建议追踪三个核心指标：每次 parse 调用的边界迁移耗时与计算耗时比值、流式处理中单字符的平均解析次数、以及 JIT 编译预热后的性能提升倍率。当边界耗时比值超过 0.5 时，应评估数据传递方式的合理性；当单字符解析次数随流式长度线性增长时，表明存在重解析问题，需引入增量解析机制。
本案例的核心启示在于：性能优化的第一优先级是定位真正的瓶颈所在，而非预设某项技术的性能优势。对于结构化文本解析这类位于 JavaScript 引擎优化甜蜜点的工作负载，边界成本与算法复杂度才是决定性因素，盲目追求 WASM 反而可能导致性能倒退。
资料来源：OpenUI 技术博客《Rewriting our Rust WASM Parser in TypeScript》（openui.com/blog/rust-wasm-parser）