Rust‑WASM パーサーを TypeScript に書き直した結果、処理速度が 3 倍に向上しました。

私たちがRustで書いた openui‑lang パーサを WASM にコンパイルした理由

ロジックはまったく正しかった。

• Rust は高速
• WASM ならブラウザ上でもほぼネイティブ速度
• 我々のパーサはそれなりに複雑なマルチステージパイプライン

というわけで、Rust + WASM がベストだと考えていた。
しかし実際には「最適化すべきところ」を誤っていたのである。

パイプライン

id = expression

OutputNode

パーサはストリーミングチャンクごとに呼び出されるため、レイテンシは極めて重要である。

WASM 境界オーバーヘッド

WASM パーサを呼び出すたびに発生する必須のオーバーヘッドは、Rust コード自体が高速であっても無視できないものだった。

JS 世界          | WASM 世界
───────────────────────────────────────
wasmParse(input)
  │
  ├─ JS ヒープ → WASM 線形メモリへ文字列コピー (割り当て + memcpy)
  │
  │                                 Rust が高速にパース ✓
  │                                 serde_json::to_string() ← 結果をシリアライズ
  │
  ├─ WASM → JS ヒープへ JSON 文字列コピー (割り当て + memcpy)
  │
  JSON.parse(jsonString)              ← 結果をデシリアライズ
  │
return ParseResult

実際に遅いのは Rust のパース 自体ではなく、境界処理である。
文字列を WASM にコピーし、結果を JSON 化して再び JS に渡し、V8 がその JSON を解析するという一連の操作がコストを押し上げていた。

「直接オブジェクト渡し」は逆に遅い

serde-wasm-bindgen

JsValue

理由は、JS が WASM 線形メモリ上のバイト列をそのままネイティブオブジェクトとして解釈できないためである。
Rust のデータ構造（ポインタ、enum 判別子、アラインメントパディングなど）は JS 実行環境には完全に透明であり、

serde-wasm-bindgen

parse()

JSON アプローチと比較すると：

• serde_json::to_string()

  は純粋な Rust で実行され、境界を一度も越えない
• 生成された文字列は1回だけコピーされ、V8 のネイティブ C++

  JSON.parse

  が単一の最適化済みパスで処理する

大きくて少数の操作 の方が多く細かい操作より勝る。

この変更はすぐに取り消した。

TypeScript 実装への移行

パーサ全体を TypeScript に書き直した。

• ステージ数は同じ（6）

• ParseResult

  の形も同じ
• WASM は使わず、V8 ヒープ内で完結

ベンチマーク手法：ワンショットパース

parse(completeString)

performance.now()

WASM を排除したことで、呼び出しごとのコストは劇的に減少。
しかしストリーミングアーキテクチャ自体にはさらに深い非効率が残っていた。

ストリーミングの非効率

パーサは LLM の各チャンクごとに呼び出される。
単純な戦略では、チャンクを蓄積して文字列全体を再度ゼロからパースする：

Chunk 1: parse("root = Root([t")              → 14 chars
Chunk 2: parse("root = Root([tbl])\ntbl = T") → 27 chars
...

1000 文字の出力を 20 文字ずつ配信した場合、
50 回のパースで約 25 000 文字を処理し、計算量は O(N²)。

修正：文単位増分キャッシュ

深さ 0 の改行で終端された文は不変（LLM は再度変更しない）とみなし、
完了した文の AST をキャッシュするストリーミングパーサを導入：

State: { buf, completedEnd, completedSyms, firstId }

push(chunk) で
  1. completedEnd 以降から深さ0改行をスキャン
  2. 完了文ごとに parse + cache AST → completedEnd を進める
  3. 残り（最後の不完全文）: autoclose + fresh parse
  4. キャッシュ済み + 未完結文をマージして resolve + map → ParseResult

• 完了した文は再パースされない
• チャンクごとに 残り1文だけ を再解析する

これで計算量は O(総文字数) へ改善。

ベンチマーク手法：全ストリーム総パースコスト

parse()

push()

simple-table

発見事項まとめ

WASM から TypeScript に切り替えたことで、呼び出しごとのパフォーマンスは 2.2〜4.6 倍向上。
さらにアルゴリズムを O(N²) → O(N) に改善した結果、全ストリームコストは 2.6〜3.3 倍低減。

学んだ教訓

1. 実際に時間がかかっている場所をプロファイルする
   言語選択の前に、計算自体よりデータ転送（境界オーバーヘッド）がボトルネックになることが多い。

2. serde-wasm-bindgen

   で直接オブジェクト渡しは必ずしも高速ではない
   Rust の内部レイアウトを JS が解釈できないため、フィールド単位で再構築する必要がある。結果として境界越え回数が増える。

3. アルゴリズム的改善が言語レベルの最適化よりも大きいインパクトを持つ
   O(N²) から O(N) にした方が、WASM → TS の切替よりも実際に速くなるケースが多い。

4. WASM と JS はヒープを共有しない
   WASM の線形メモリは生のバイト列であり、JS にはポインタや enum 判別子などが透明である。常に変換コストが発生する。

WASM が有効なケース

• 計算負荷が高く、相互作用が少ない
  画像/動画処理、暗号化、物理シミュレーション、オーディオコード化など。入力は大きいが出力はスカラーか in‑place 修正のみで、境界越え頻度が極めて低い。

• 既存のネイティブライブラリを再実装せずに使いたい
  SQLite, OpenCV, libpng など C/C++ ライブラリをブラウザへそのままデプロイできる。

WASM があまり有効でないケース

• 構造化テキストを JS オブジェクトに変換するパース
  シリアライズコストは必須。Rust の高速計算が V8 の JIT を上回る余裕がなく、境界オーバーヘッドが支配的。

• 小さな入力で頻繁に呼び出される関数
  呼び出し 50 回／ストリーム、1 回あたり計算時間 5 µs の場合、境界コストを摊り切れない。

結論

まずは アルゴリズムの効率化（O(N²) → O(N)） を優先し、次に「明らかなパフォーマンスメリットがある」場面でだけ言語／ランタイムを切り替える。
そうすることで、クリーンで高速、保守性の高いパーサーパイプラインを実現できた。