## Hardware in PR #84

The PR's benchmarks ran on an **Apple M2 Max, 12 physical cores, 32 GB RAM, macOS Sequoia 15.3**, with `--max-concurrency=12`, on a 60 MB Wikipedia markdown subset of **3,142 files** (median 19 KB, largest 1.2 MB). Methodology: `hyperfine`, 10 warm runs after 3 cold discards. Reported time: **278.3 ms ± 6.4 ms** (rounded to 280 ms in the PR body), with the cold-room caveat that Hiroshi ran the final bench at 06:30 JST on a Sunday with no Spotlight/background tasks.

## v0.5.0 release-notes figure for the same corpus

The release notes (`releases/release-v0.5.0-2026-06-08.md`, "Benchmark detail") report the Large / Wikipedia-subset row as **280 ms** on v0.5.0 vs 7,400 ms on v0.4.2 — a 26.4× speedup. But the surrounding caption disagrees with the PR on several environment details:

| Field | PR #84 | v0.5.0 notes |
|---|---|---|
| Wall-clock (60 MB) | **280 ms** | **280 ms** |
| `--max-concurrency` | 12 | 8 (table caption) |
| File count in 60 MB corpus | 3,142 | 1,200 |
| macOS version | Sequoia 15.3 | 14.5 |
| Runs | 10 warm + 3 cold discards | median of 5, `--warmup 2` |

## Consistency

The **headline number is identical (280 ms)** but the **measurement conditions reported around it are not**. Same hardware family (M2 Max), but different concurrency setting, different corpus file count for the "same" 60 MB Wikipedia subset, different macOS version, and a different `hyperfine` run plan.

The most plausible explanation — given the surrounding evidence in the docs themselves — is that the release-notes table reused the 280 ms cell from the PR while pairing it with a separately-drafted environment caption. Two specific hints support this:

1. The release notes' own "Notes" line says "the 26× gain ... is partly from the AST flattening fix (#41) and partly from parallelism … the flattening fix alone gave ~3.2×; concurrency gave the remainder." The PR thread frames the same 26× as v0.4.x→PR #84 (sequential→concurrent dispatch) with the bumpalo step…

## PR #84 hardware

From `pr_threads/pr-084-concurrent-processing.md`: **Apple M2 Max, 12 physical cores, 32 GB RAM, macOS Sequoia 15.3.** Corpus described as a 60 MB Wikipedia markdown subset, **3,142 files** (median 19 KB, largest 1.2 MB). Methodology: 10 warm runs after 3 cold discards via hyperfine; flame graph captured with `--max-concurrency=12`.

Reported 60 MB wall-clock with PR #84 applied: **280 ms** (vs. 3.1 s post-bumpalo, 7.4 s on v0.4.x baseline).

## v0.5.0 release notes

From `releases/release-v0.5.0-2026-06-08.md`: same M2 Max class machine, but the bench table header reads **macOS 14.5, `--max-concurrency=8`**, and the "Large (Wikipedia subset)" row lists **1,200 files / 60 MB**, with the v0.5.0 time at **280 ms** (vs. 7,400 ms on v0.4.2, 26.4× speedup). Times are described as median of 5 runs with `hyperfine --warmup 2`.

## Consistency

**The headline wall-clock figure agrees: 280 ms for the 60 MB corpus, with the same ~26× speedup vs. v0.4.x.** That's the load-bearing number and it matches.

The surrounding metadata does **not** fully line up, though:

| Field | PR #84 | v0.5.0 release notes |
|---|---|---|
| Wall-clock @ 60 MB | 280 ms | 280 ms ✅ |
| Hardware | M2 Max, 12-core, 32 GB | M2 Max (unspecified spec) |
| OS | macOS Sequoia 15.3 | macOS 14.5 |
| File count in 60 MB corpus | 3,142 | 1,200 |
| `--max-concurrency` | 12 (flame graph cmd) | 8 (bench table) |
| Run count | 10 warm + 3 cold discards | median of 5, `--warmup 2` |

So the figures are **consistent on the headline result but inconsistent on the supporting parameters** — different OS minor version, different corpus file count (same 60 MB total, so subsampling granularity differs), different concurrency cap, different hyperfine recipe. The two documents were authored separately (PR body finalized 2026-06-02, release notes shipped 2026-06-08) and appear to reflect distinct benchmark runs against the same workload class rather than one canonical run quoted twice. There's also a sepa…