性能の測定結果

Node v22.23.3、macOS arm64上でのローカル測定です。開発用マシンで観測した結果であり、別のマシンでの性能を保証するものではありません。コンパイラ生成物のハッシュは 5cf2efd81f4efa03d51c4e0715523d6e76bef962a4b2e0a66194d0876bb13a13、サイズは2,250,901バイトです。

コンパイラ

最終のセルフブートストラップでは、コンパイラの2回のコンパイルに約79.3秒と77.4秒を要しました。stage 1・2・3はバイト単位で一致しました。各段階で1,559,693回の上限付き呼び出しを行いました。1回の呼び出しで計上した割り当ての最大値は161,720バイトです。観測したプロセスのピークRSSは約426MBと482MBでした。これは言語の状態だけでなく、コンパイラの実行を取りまとめるプロセスも含みます。

ベンチマークは各ケースをウォームアップして5サンプルを測定しました。中央値は次のとおりです。

ケース	呼び出しごとにrunnerを作成	runnerを再利用
小さな出力プログラム	26.47 ms	14.23 ms
算術・出力の100回の列	702.49 ms	628.93 ms

2番目のケースには明らかなばらつきがあり、再利用時は598.56〜872.44msでした。中央値だけから、常に高速化すると判断しないでください。createRunner はコンパイル済み関数のクロージャーと実行メタデータを再利用し、呼び出しごとの状態と予算はリセットします。同時の再利用は拒否します。

DaaS

最大サイズの100件生成リクエストは、元は6,400個の乱数ワードを取得していたため、割り当て計上が約5,620,348バイトでした。各サンプルの棄却処理と、枯渇時に返す上限付きのResultを維持しながら、取得を count + 64 ワードへ変更すると、同じランタイムで約178,653バイトになりました。これは言語の累積割り当て計上であり、プロセスのメモリー使用量ではありません。最適化後のリクエストは24回のホスト呼び出しと約14,574単位のfuelを使い、従来どおりの128呼び出し、100,000fuel、8MiBの上限内に収まりました。

テストには、偏りを生む乱数末尾の棄却、乱数枯渇時にDBへ書き込まないこと、同時実行のアトミックな加算、スキーマ・オーバーフローの失敗、不正なUTF-8、認証の再試行動作を含めています。言語のプロパティテストでは別途、不変コレクションの操作を独立した配列モデルと比較し、生成した反例を縮小します。