Reproduce the benchmark before trusting the number.

The published fixture includes the commit, environment, sample count, measured range, and scope boundary. Then use the same discipline on repositories your team ships.

Install Radar Benchmark docs

Verified benchmark

Measured on a maintained fixture, not invented for a landing page.

The figures below come from the repository's Criterion benchmark suite and include a reproducible environment, fixture, commit, and range.

Measured: 2026-08-08
Version: 1.0.0 · 0fb2efc
Method: Criterion 0.5.1 · radar-bench/parse_and_query

TypeScript parse · direct10.566 ms

10.546–10.595 ms

TypeScript parse · cache miss10.753 ms

10.703–10.819 ms

TypeScript parse · cached71.038 µs

70.938–71.168 µs

Run 10 maintained TypeScript queries36.096 ms

35.953–36.254 ms

Compile catalog and run 10 TypeScript queries62.155 ms

61.881–62.479 ms

All maintained AST rules25.266 ms

25.185–25.368 ms

Scan summary · empty cache13.538 ms

13.494–13.586 ms

Scan summary · persistent cache8.404 ms

8.356–8.469 ms

FixtureSynthetic TypeScript · 5,002 lines · 130,884 bytes

EnvironmentApple M2 · 8 cores · 16 GB · macOS 27.0 · arm64

MethodOptimized bench profile · 3 s warm-up · 100 measured samples

Benchmark source: crates/radar-bench/benches/parse_and_query.rs
Source SHA-256: 7c40e89a4d63314e0fb95f50226621b6c806950817d94bfdc5b5cc0827917e58
Fixture SHA-256: 226cab8c9fc6c1af4ba30e550e1a7d469b6e9741822487ef1d64b02febb0bb22

Scope boundary

These measurements cover the maintained parser, rule, and scan-session fixture. They are not an end-to-end speed promise for every repository, machine, ruleset, or network condition.

Reproduction requires access to the source checkout at the measured commit.

Interpret the benchmark before comparing speed

Code Radar benchmarks measure a named fixture under a documented environment and commit. Cold, warm, parser, rule, and scan-session values describe that reproducible run; they are not a universal promise for every codebase, machine, filesystem, or rule configuration.

A trustworthy measurement includes fixture and source hashes, hardware and software environment, sample count, measured range, command, warm-up behavior, and a clear statement of what the test excludes.
Synthetic or fixed-fixture timing cannot predict repository-specific performance by itself. File mix, cache state, dependency manifests, enabled rules, storage, runner load, and output format can change results.
Reproduce the published fixture, then run the same command discipline on a representative repository and compare both speed and finding usefulness before changing team policy.

How to validate Interpret the benchmark before comparing speed

Use a real artifact and an explicit boundary for the decision. A claim is useful only when the visitor can inspect it, reproduce the relevant step, and understand what it does not prove.

Decision areaWhat to verify

EvidenceA trustworthy measurement includes fixture and source hashes, hardware and software environment, sample count, measured range, command, warm-up behavior, and a clear statement of what the test excludes.

BoundarySynthetic or fixed-fixture timing cannot predict repository-specific performance by itself. File mix, cache state, dependency manifests, enabled rules, storage, runner load, and output format can change results.

Next stepReproduce the published fixture, then run the same command discipline on a representative repository and compare both speed and finding usefulness before changing team policy.

Questions about Interpret the benchmark before comparing speed

These answers connect the page promise to observable evidence, a clear limitation, and the next action that advances the workflow.

What evidence should I inspect for Interpret the benchmark before comparing speed?

Inspect this evidence: A trustworthy measurement includes fixture and source hashes, hardware and software environment, sample count, measured range, command, warm-up behavior, and a clear statement of what the test excludes.

What does Interpret the benchmark before comparing speed not prove?

Keep this limitation explicit: Synthetic or fixed-fixture timing cannot predict repository-specific performance by itself. File mix, cache state, dependency manifests, enabled rules, storage, runner load, and output format can change results.

What should I do after reviewing Interpret the benchmark before comparing speed?

Use the next step that matches the decision: Reproduce the published fixture, then run the same command discipline on a representative repository and compare both speed and finding usefulness before changing team policy.

Continue with the right proof or implementation path.

These pages connect the current decision to a real artifact, installation step, workflow owner, or commercial boundary.

Code Radar

Validate the workflow on your own code.

Start with one local scan, inspect the evidence, and expand to reports, agents, or CI only when the signal is useful.

Exact Criterion command

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

Install Radar Benchmark docs