メトリクス
人気のスクリプト言語と比較した V0.2.1 Keleusma CLI のリソースフットプリントと実行メトリクス。以下の数値は、組み込みまたは制約された配備を計画する運用者を対象としています。
測定方法論
すべての数値は、2026年5月に単一の Apple M1(arm64-apple-darwin23)ホスト上で測定されました。各ランナーは同じ概念的なワークロードを実行しました。ランタイムを読み込み、些細なプログラムをパースまたはロードし、整数42を印字し、終了します。ランナーごとに5回の実行。典型的な中間値が報告されています。
- バイナリサイズ:
ls -lによって報告される、ストリップされたまたはデフォルトのリリースビルドのサイズ。存在する場合はパスをreadlinkを通じて解決します。 - 最大常駐セットサイズ: macOS 上で
/usr/bin/time -lによって報告されるピーク RSS。ランタイム自身のメモリに加え、任意の時点でページ常駐しているすべての共有ライブラリを含みます。 - ピークメモリフットプリント:
/usr/bin/time -lによって報告されるピークのダーティ + 匿名メモリ。共有ライブラリのテキストページを除外するため、最大 RSS よりも低くなります。 - 経過サイクル: プロセス開始からプロセス終了までに消費された CPU サイクル。
- 実時間: プロセス開始から終了までの実時間。測定ツールによって10 msに丸められています。
Keleusma の測定は、暗号化機能スタック(X25519 + AES-256-GCM + HKDF-SHA-256)を含む、完全な厳格モード対応の CLI バイナリを実行します。測定されたバイナリは、運用者が配備するであろうものです。
結果
| ランナー | バイナリサイズ | 最大 RSS | ピークフットプリント | サイクル数 | 実時間 |
|---|---|---|---|---|---|
| bash 5.x (システム) | 1.3 MB | 1.85 MB | 1.26 MB | 6.3 M | < 10 ms |
| Keleusma 0.2.1 | 2.1 MB | 2.85 MB | 1.49 MB | 8.4 M | < 10 ms |
| Lua 5.4 (一般的な公表値) | 0.3 MB | ~2.0 MB | ~1.5 MB | ~7 M | < 10 ms |
| Python 3.13 (MacPorts) | 34 KB のランチャー + フレームワーク | 11 MB | 5.7 MB | 54.8 M | 20 ms |
| Ruby 3.1 (MacPorts) | 34 KB のランチャー + フレームワーク | 30.7 MB | 25.7 MB | 128 M | 40 ms |
| Node.js (MacPorts) | 77 MB | 42.5 MB | 13.7 MB | 108 M | 40 ms |
Python と Ruby のランチャーバイナリは共有ライブラリを読み込む小さなシムであり、実質的なコードはディスク上の Python/Ruby フレームワークの動的ライブラリに存在します。ランチャーのサイズはインストール全体の占有量を過小に見せています。Node.js は V8 とランタイムの大部分を静的リンクするため、バイナリが大きくなります。
Lua の行は、このマシンでは Lua が利用できなかったため、実測値ではなく Lua 5.4 リファレンスビルドの公表値を用いています。数値は、liblua を静的リンクした標準的な ./configure && make ビルドを代表するものです。
主要な調査結果
Keleusma のリソース消費は本質的に bash と同等の水準です。 バイナリサイズ、RSS、ピーク時の占有量、サイクル数はいずれも、同一の些細なワークロードにおいて bash の 30 パーセントから 60 パーセントの範囲に収まります。いずれのランナーも 10 ms 未満で読み込みと実行を完了します。
他のインタプリタ型スクリプト言語 (Python、Ruby、Node.js) は、同一のワークロードに対して 5 倍から 20 倍のメモリ圧迫と 7 倍から 15 倍の CPU サイクルを要します。それらの利点はエコシステムであり、その代償が占有量です。
Keleusma は bash や Lua と同じ運用上のクラスに位置づけられながら、そのいずれよりも大幅に多くの保証を提供します。次の節では、このわずかなオーバーヘッドと引き換えに運用者が得られるものを説明します。
運用者が得られるもの
bash に対しておよそ半メガバイトの追加バイナリと 1 メガバイトの追加 RSS と引き換えに、Keleusma のデプロイには次のものが含まれます。
- 検証済みバイトコード: スクリプトはメモリの問題、無限ループ、無限再帰によってクラッシュすることがありません。構造検証器は、境界を打ち破るようなプログラムを拒否します。
- 静的に算出された WCMU および WCET の境界: アリーナのメモリは、バイトコードが宣言した境界とちょうど同じ大きさに確保されます。bash と Lua には同等の仕組みがありません。
- Ed25519 による署名付き配布: スクリプトはリリース鍵に対して暗号的に認証されます。bash スクリプトは別途のツール (gpg、codesign) を用いて外部で署名できますが、実行時の検証は組み込まれていません。
- X25519 と AES-256-GCM による暗号化配布: スクリプトは特定の宛先ホストに対して暗号化されます。成果物単体から平文を読み取ることはできません。
- 情報フローラベル: 型システムレベルのデータフロー追跡により、ポリシー違反をコンパイル時に検出します。bash や他のスクリプト言語には静的な情報フロー制御 (IFC) がありません。
- 厳格モードのポリシーゲート: CLI は、署名済みかつ復号可能な成果物のみが実行されることを強制します。ファイルシステムと環境変数を通じて設定可能です。スクリプト側のいかなる仕組みでも回避することはできません。
これらの機能はいずれも運用者に大きな占有量の負担をかけません。暗号スタックはバイナリに約 200 KB を追加します (合計 2.1 MB のうち)。厳格モードのポリシー機構は残りのうちのわずかな部分です。
機能ごとの占有量の内訳 (概算)
| 機能 | バイナリへの寄与の概算 |
|---|---|
| コアのコンパイラと仮想マシン (パーサ、型検査器、検証器、実行器) | ~1.4 MB |
signatures 機能 (Ed25519) | ~150 KB |
encryption 機能 (X25519、AES-GCM、HKDF、SHA-256) | ~200 KB |
shell 機能 (プロセス生成、環境変数、終了) | ~50 KB |
| CLI の表層 (引数解析、REPL、鍵生成、厳格モードのポリシー) | ~250 KB |
| ストリップ済みリリースバイナリの合計 | 2.1 MB |
ある機能を必要としない組み込み者は、Cargo の機能フラグを通じてそれを省略できます。--no-default-features --features compile,verify による最小限の組み込みビルド (暗号化なし、署名なし、シェルなし) は約 1.2 MB です。ホストアプリケーションにリンクされるライブラリのみのビルドは CLI の表層を持たず、追加バイナリは約 800 KB から 1 MB です。
ループデーモンのワークロード
無期限の loop main を 1 ミリ秒あたり 1 反復で 1 分間 CLI 下で実行すると、およそ次のリソースを使用します。
- 一定の 2.9 MB の RSS (実行を通じて増加しません。アリーナは起動時に大きさが確保されます)
- M1 コア 1 個の 1 パーセントから 2 パーセント (ティックレートが支配的であり、反復あたりのコストはマイクロ秒単位です)
- アロケータ圧迫ゼロ (アリーナの一時領域は yield-resume サイクルごとにリセットされます)
Python や Ruby における同等の定常状態のデーモン挙動は、空のループ本体に対して 15 MB から 30 MB の RSS と、同等かそれ以上の CPU 使用率で動作します。デーモンの稼働時間が延びるにつれて、この優位性は累積的に大きくなります。
スリープ間隔での定常状態
--tick-interval 1s の下で 1 秒あたり 1 ティックの場合、デーモンの CPU は実質的にゼロまで低下します (反復あたりの計算はマイクロ秒単位で、約 999.9 ms はレートリミッタのスリープでアイドル状態です)。アリーナは起動時に大きさが確保されて再利用されるため、RSS は高レートのワークロードから変化しません。ドリフト補償されたスリープにより、典型的な稼働期間にわたる累積ドリフトは 1 パーセント未満に抑えられます。
長間隔のデーモン (--tick-interval 1h、--tick-interval 1d) では、CPU 使用率は Keleusma 自体ではなく OS スケジューラのウェイクアップ機構が支配的です。ランタイムは反復の合間に真にアイドル状態です。1 時間あたり 1 ティックのメモリ常駐型デーモンは、運用上 2.9 MB の常駐メモリマッピングと同じリソースを消費します。そのコストは計算ではなく、ページフォルトの回避です。メモリ常駐型デプロイの運用者ガイドについては SECURITY_POLICY.md を参照してください。
比較に関する注記
この比較は意図的に選択的です。各ランナーは設計目標が異なり、直接的な機能比較は公正ではありません。
- bash: シェルインタプリタ。一般的なプログラミングではなくシェルパイプライン向けに設計されています。文ごとの検証が少ないため Keleusma より起動が速いものの、静的な型検査、境界付きリソース解析、署名検証はありません。
- Lua: 組み込み可能なスクリプト言語。運用上の占有量において Keleusma に最も近い類似物です。Lua は無限再帰と無限ループを許容し、実行時エラーが起こり得ます。WCMU や WCET の境界はありません。組み込みの署名や暗号化もありません。
- Python、Ruby: 豊富な標準ライブラリを備えた汎用の動的言語。運用上より重く、型エラーは実行時にのみ検出されます。境界付きリソース解析はありません。署名と暗号化はサードパーティのパッケージを通じて利用できますが、組み込みではありません。
- Node.js: V8 と Node ランタイム。高スループットのサーバワークロード向けに設計されており、JIT が長時間稼働するサービス全体で起動コストを償却します。単発のスクリプトには重すぎます。コードの組み込みの署名や暗号化はありません。
Keleusma が真に優位となる場面: 検証済みの実行特性を必要とするデプロイ (規制産業、組み込み)、および CLI が多数の短命なスクリプトを実行するデプロイ (スクリプトごとのオーバーヘッドが低い)。比較対象が優位となる場面: 豊富なエコシステムを必要とし、起動コストが長時間稼働するサービス全体で償却されるデプロイ。
再現性
上記の測定値は 2026 年 5 月 22 日に次のコマンドで生成されました。運用者は自身のハードウェアで再現できます。
# Build keleusma CLI release binary
cargo build --release -p keleusma-cli
# Trivial source program
echo 'fn main() -> Word { 42 }' > /tmp/hello.kel
# Measure
/usr/bin/time -l ./target/release/keleusma run /tmp/hello.kel
# Comparators (where installed)
/usr/bin/time -l bash -c 'echo 42'
/usr/bin/time -l lua -e 'print(42)'
/usr/bin/time -l python3 -c 'print(42)'
/usr/bin/time -l ruby -e 'puts 42'
/usr/bin/time -l node -e 'console.log(42)'
数値はホスト CPU、OS バージョン、インストールされたランタイムのバージョンによって変動します。相対的な順序 (bash と Keleusma が下位、インタプリタ言語が上位) は、私がテストしたマシン全体で安定しています。