数値を信頼する前にベンチマークを再現。

公開 fixture には commit、環境、サンプル数、測定範囲、境界を含みます。同じ基準を自社リポジトリにも適用します。

検証済みベンチマーク

ランディングページ用に作った数値ではなく、保守された fixture で測定。

以下は再現可能な環境、fixture、commit、範囲を含む Criterion の測定値です。

測定日
2026-08-08
Version
1.0.0 · 0fb2efc
方法
Criterion 0.5.1 · radar-bench/parse_and_query
TypeScript 解析 · 直接10.566 ms

10.546–10.595 ms

TypeScript 解析 · キャッシュミス10.753 ms

10.703–10.819 ms

TypeScript 解析 · キャッシュ済み71.038 µs

70.938–71.168 µs

保守されている TypeScript クエリ 10 件を実行36.096 ms

35.953–36.254 ms

カタログをコンパイルして TypeScript クエリ 10 件を実行62.155 ms

61.881–62.479 ms

保守されている全 AST ルール25.266 ms

25.185–25.368 ms

スキャン概要 · 空キャッシュ13.538 ms

13.494–13.586 ms

スキャン概要 · 永続キャッシュ8.404 ms

8.356–8.469 ms

FixtureSynthetic TypeScript · 5,002 lines · 130,884 bytes
環境Apple M2 · 8 cores · 16 GB · macOS 27.0 · arm64
方法最適化ベンチマークプロファイル · 3秒のウォームアップ · 100回の計測サンプル
ベンチマークソース
crates/radar-bench/benches/parse_and_query.rs
ソース SHA-256
7c40e89a4d63314e0fb95f50226621b6c806950817d94bfdc5b5cc0827917e58
fixture SHA-256
226cab8c9fc6c1af4ba30e550e1a7d469b6e9741822487ef1d64b02febb0bb22
適用範囲

この測定は保守された parser、rule、scan-session fixture が対象です。すべてのリポジトリ、マシン、ルール、ネットワークでの終端速度を保証しません。

再現には、測定したコミットのソースチェックアウトへのアクセスが必要です。

速度比較の前に benchmark を解釈する

Code Radar benchmark は文書化した環境と commit で指定 fixture を測定します。cold、warm、parser、rule、scan-session の値は再現可能な実行を示し、すべてのコードベースへの約束ではありません。

  • 信頼できる測定には fixture と source の hash、hardware と software 環境、sample 数、測定範囲、command、warm-up、除外範囲が含まれます。
  • 固定 fixture だけではリポジトリ固有の性能を予測できません。ファイル構成、cache、manifest、rule、storage、runner 負荷、出力形式で結果は変わります。
  • 公開 fixture を再現し、代表的なリポジトリにも同じ測定手順を適用して、速度と検出の有用性を比較してからチーム方針を変えます。

速度比較の前に benchmark を解釈する の検証方法

実際の成果物と明確な境界を使います。確認でき、関連手順を再現でき、何を証明しないか理解できる主張だけが判断に役立ちます。

判断領域確認する内容
根拠信頼できる測定には fixture と source の hash、hardware と software 環境、sample 数、測定範囲、command、warm-up、除外範囲が含まれます。
限界固定 fixture だけではリポジトリ固有の性能を予測できません。ファイル構成、cache、manifest、rule、storage、runner 負荷、出力形式で結果は変わります。
次の手順公開 fixture を再現し、代表的なリポジトリにも同じ測定手順を適用して、速度と検出の有用性を比較してからチーム方針を変えます。

速度比較の前に benchmark を解釈する に関する質問

以下ではページの約束を観察可能な根拠、明確な限界、ワークフローを進める次の行動へつなげます。

速度比較の前に benchmark を解釈する ではどの根拠を確認すべきですか?

次の根拠を確認します。信頼できる測定には fixture と source の hash、hardware と software 環境、sample 数、測定範囲、command、warm-up、除外範囲が含まれます。

速度比較の前に benchmark を解釈する が証明しないことは何ですか?

この限界を明示します。固定 fixture だけではリポジトリ固有の性能を予測できません。ファイル構成、cache、manifest、rule、storage、runner 負荷、出力形式で結果は変わります。

速度比較の前に benchmark を解釈する を確認した後は何をすべきですか?

判断に合う次の手順を使います。公開 fixture を再現し、代表的なリポジトリにも同じ測定手順を適用して、速度と検出の有用性を比較してからチーム方針を変えます。

適切な検証または実装へ進む。

以下のページは現在の判断を実際の成果物、導入手順、ワークフロー責任、または商用境界につなげます。

自分のコードでワークフローを検証します。

1 回のローカルスキャンから始め、証拠を確認し、信号が有用な場合だけレポート、エージェント、CI へ広げます。

git checkout 0fb2efc
shasum -a 256 crates/radar-bench/benches/parse_and_query.rs crates/radar-bench/benches/fixtures/synthetic_large.ts
cargo bench -p radar-bench --bench parse_and_query