OmoikaneのRealm生成が遅かったので、Boaのscope検索と字句解析を調べた

Tue, 29 Sep 2026 18:25:00 +0900

OmoikaneのCIの待ち時間を調べた記事では、文書だけの変更に重い検証を走らせないことや、ビルドキャッシュを見直した話を書いた。それとは別に、実行する必要のあるテストそのものにも時間がかかっていた。

OmoikaneはJavaScriptの実行にBoaを使っている。ページやiframeのためにJavaScriptのRealmを作るたび、DOM APIを用意する大きなスクリプトを実行する。その処理がテスト時間の相当部分を占めていた。Issue #1154では、テストの数やRealmの数を減らすのではなく、この初期化そのものを調べた。

先に結果を書くと、macOSのtest profileでRealm生成時のbootstrap処理は約0.58秒から約0.13秒になった。ただし、これはrelease buildのページ表示時間を測った結果ではない。何を測り、どこを変えたらそうなったのかを順に残しておく。

Realmを作るたびに何が起きていたか

RealmはJavaScriptの組み込みオブジェクトやグローバル環境を持つ実行単位で、Omoikaneではページやiframeごとに必要になる。Realm自体については以前の記事に書いた。

新しいRealmを作ると、OmoikaneはDOMをJavaScriptから使えるようにするbootstrapを読み込む。dom_bootstrap.js、xpath.js、font_loading.js、find_in_page.jsを連結したソースは約1.1MBある。evaluate_dom_bootstrapはそのソースをmoduleとして解析し、load、link、evaluateまで進める。内部のhost bindingをページのglobalに露出させていないかも、この初期化時に確認している。

Realmを作る
 ↓
bindings.module_source() 約1ms
 ↓
Module::parse 約335ms
 ↓
module.load + link 約240ms
 ↓
module.evaluate 約10〜25ms

これは変更前に一回だけ実行したときの、おおよその内訳である。全体で約0.58秒かかる。特にparseとload・linkが重かった。bootstrapソースは毎回ほぼ同じなのに、Realmごとに解析とコンパイルを繰り返している。

一時的な計測コードを入れてlibのユニットテストを全件走らせると、1069件のテストからbootstrapが計1414回呼ばれていた。0.58秒を掛けると約820秒になる。libテストのCPU時間は約1160秒だったので、概算で7割ほどがこの初期化に対応する。一方、実時間は160〜222秒だった。テストが並列に走るため、CPU時間と時計で測った実時間は同じ値にはならない。

実際、Realmを25個作るテストは単体で16.1秒、13個作るテストは7.8秒かかっていた。遅いテストを一つだけ削っても、根本の費用は残る。そこで「bootstrapを何度も処理しない」「処理するなら処理自体を速くする」の両方を検討した。

最初の案は解析済みmoduleのキャッシュだった

最初に立てた子Issue #1155は、解析済みのbootstrap moduleをプロセス内でキャッシュするというものだった。同じソースを何度もModule::parseへ渡すのだから、一回作ったASTを使い回せれば分かりやすい。

ただ、Boaの解析結果をそのままスレッド間で共有できるわけではない。ASTのScopeはRcとRefCellを含み、ASTのシンボルはContextごとのInternerにも依存している。libtestはテストごとに別スレッドで動く。測定した1414回のうち、同じスレッドで二回目以降のRealmを作ったのは345回だけだった。残りの大半には、スレッド内だけのキャッシュを置いても効かない。

「キャッシュすればよい」という方向で実装を進める前にプロファイルを取ると、別の問題が見えた。解析とコンパイルの上位に、JsStringの比較がいた。呼び出し元は、Boaのscope解析やbytecode生成で行うbindingの名前検索だった。

大きなscopeを何度も線形探索していた

JavaScriptの変数や関数の名前を解決するとき、パーサーとコンパイラはscopeのbindingを調べる。Boaでは、そのbindingを宣言順のVecに持ち、名前を探すたびに先頭から比較していた。小さな関数のscopeならこれで十分だが、DOM bootstrapのmoduleトップレベルには大量のbindingがある。

名前の参照が増えるたびに、長いリストをまた走査する。binding数をB、参照数をRとすれば、この部分の仕事はおおむねR × Bに増える。約1.1MBのソースをRealmごとに処理すると、その費用を毎回払うことになる。

PR #1160では、宣言順のVecは残し、名前からその位置を引けるFxHashMapを追加した。ただし、すべてのscopeに最初からハッシュ表を持たせたわけではない。bindingが16件以下なら従来どおり線形探索し、17件目を追加したときに索引を作る。普通の小さなscopeで索引の確保費用が増えるのを避けるためだ。

bindingは追加されるだけで、削除や改名はしない。そのため索引に入れたVec上の位置は後から無効にならない。宣言順、binding index、外側のscopeからの参照、再宣言、escapeの扱いは変えない。しきい値の前後でこれらが変わらないこともテストした。

結果は、単なるparseの短縮にとどまらなかった。名前検索はscope解析だけでなくbytecode生成でも使われるため、load・linkも大きく短くなった。

処理・計測範囲	変更前	scope索引化後
bootstrapの`Module::parse`	約335ms	約115ms
bootstrapの`load` + `link`	約240ms	約25ms
libユニットテストのCPU時間	1160秒	427秒
libユニットテストの実時間	160〜222秒	63秒

これはmacOS 8コアのtest profileでの測定である。libテストの実時間に幅がある変更前の値を使っているため、単一条件の厳密な倍率として読まない方がよい。ただ、解析だけをキャッシュする案では残っていたはずのコンパイル側まで改善したのは大きい。

パフォーマンス

OmoikaneのRealm生成が遅かったので、Boaのscope検索と字句解析を調べた

Realmを作るたびに何が起きていたか

最初の案は解析済みmoduleのキャッシュだった

大きなscopeを何度も線形探索していた