分析処理のベンチマーク
イベント数とゲート数を変えて分析時間を計測しました。計測結果に加え、条件、処理上限、再現手順を掲載しています。 インシデントは証拠としてイベントごとに集約されるため、件数が増えてもグラフのノード数は増えません。
データの流れ
01
集約 インシデントを部位と故障モードごとに集計し、イベントの確率に反映します。件数が増えてもノード数は増えません。
02
伝播 メカニズムグラフにはループも記録できます。 のループがある枝や深さの上限に達した枝は、処理を打ち切って理由を返します。
03
分析 ハザードごとにツリーを生成し、決定論的に計算します。
実測値
全計算・保存 What-if中央値
| イベント | ゲート | 全計算・保存 | What-if中央値 | What-if/秒* |
|---|---|---|---|---|
| 50 | 8 | 36 ms | 3.7 ms | 約270 |
| 200 | 30 | 138 ms | 24.0 ms | 約41 |
| 500 | 72 | 445 ms | 120.2 ms | 約8.3 |
| 1000 | 144 | 1.35 s | 701 ms | 約1.4 |
* 単一ストリームでの中央値から換算しています。2026年8月8日にApple Mシリーズの開発機で、 Docker上のリリースビルドを使い、各ゲートの分岐数を8にそろえたORツリーを計測しました。 「全計算・保存」には、証拠の定量化、カットセットの列挙、重要度の計算、固定シードによる モンテカルロ計算、リビジョンの記録を含みます。What-if分析は20回の中央値です。 この処理では、デバッグビルドはリリースビルドより約30倍遅くなります。
処理上限
数十〜数百イベントの範囲では、再計算とWhat-if分析はいずれもミリ秒単位でした。 このベンチマークのツリー構成では、分析時間はイベント数の約1.7乗に比例して増加します。 1,000イベントのWhat-if分析には約0.7秒かかりました。処理が上限に達した場合は、その内容をレスポンスで確認できます。
- カットセット：各ゲートについて確率の高いものから10,000件まで保持し、切り捨てた分の確率質量をレスポンスに含めます。
- 伝播の深さ：深さ24で打ち切り、対象の枝と理由を
cut_branchesに列挙します。 - k-of-n展開：組み合わせ数が64を超えると、展開を打ち切ります。それ以上の冗長構成は、目視でのレビューが難しくなるためです。
再現手順
ターミナルbash
docker compose -f deploy/docker-compose.yml -p bench up -d
CAUSAL_DB_URL=http://localhost:9876 python3 tools/benchmark-analyze.py