最近在做一个终端 UI 的 flex 布局引擎,叫 Pilates 。纯 TypeScript,零运行时依赖,跟 Ink 用的 WASM Yoga(Facebook 的 flex 引擎,C++ 编译成 WASM)对照过 33 个 oracle fixture 加一个结构化 fuzzer 。
本周发的 2.0 想分享一下:在我跑的 9 个基准场景里,纯 TS 引擎都比 WASM Yoga 快。包括 hot-structural(每帧 append + remove 一行),这个场景一周前 Yoga 还领先 5×,现在反过来 Pilates 快 1.7×。
中位延迟,win32-x64,Node 22:
| 场景 | Pilates | Yoga | 比率 |
|---|---|---|---|
| tiny (10 节点) | 4.5µs | 19.0µs | 4.2× |
| realistic (~100) | 121µs | 328µs | 2.7× |
| stress (~1000) | 601µs | 1.94ms | 3.2× |
| big (~5000) | 3.32ms | 9.17ms | 2.8× |
| huge (~10000) | 8.62ms | 18.5ms | 2.1× |
| hot-relayout | 16.3µs | 83.0µs | 5.1× |
| hot-relayout + boundaries | 15.8µs | 77.8µs | 4.9× |
| hot-relayout (文本变更) | 8.9µs | 90.6µs | 10× |
| hot-structural | 71.3µs | 118.3µs | 1.7× |
提前说一下:9 个场景是我自己挑的,不能代表所有 workload 。复现 pnpm bench,5 分钟。
这周做的两件事让 hot-structural 从 ~450µs 降到 ~70µs:
flex 分配规则之前每个 cell 都依赖前面所有兄弟的尺寸,一行 100 cell 就有 ~300 条依赖边。改成线性递推,每个 cell 只读前一个 cell 的位置和尺寸。
大概一半的 grammar input field 永远停留在默认值上(margin 0, minWidth 0 那种)。在 grammar 构建期把它们 fold 成常量,每个 cell 的字段数从 ~15 降到 ~7 。
公开 API 跟 1.x 字节级一致,calculateLayout() 没变,升级就有提速。
仓库(MIT):https://github.com/pilatesjs/pilates npm:https://www.npmjs.com/package/@pilates/core
欢迎对抗性 benchmark,如果有 workload 是这个方案破解不了的,我很想看看。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。