What will header maintenance cost?¶

A check adds its measured runtime to a serial development workflow. A full year refresh takes the repair time below when every selected file has an eligible stale header. Missing or conflicting headers still need review. Select a chart to view it at full size.

Each panel has its own vertical scale starting at zero. Bar heights show the relative gap at that codebase size; labels show median time in milliseconds.

How much waiting does a check add?¶

For 10,000 mixed-language files, a routine check adds 36 ms in this run: 0.36% on top of a 10-second serial workflow. A check reporting 10,000 stale headers takes 62 ms.

For your workflow, use check time / existing workflow time × 100 to estimate the percentage added. The generated HTML report lets you enter your own duration. Installation, hook orchestration and CI queueing are outside these measurements.

How long will an entire codebase take to fix?¶

Repairing stale years in all 10,000 files takes 147 ms, down from 428 ms in the previous LMH. HawkEye takes 125 ms: LMH wins the two check cases here; its repair median remains 17.6% slower.

Both tools get the same CPU budget. LMH uses up to four available workers for trees of at least 256 files. LMH keeps year-only edits, exact-byte/identity revalidation, mode preservation, atomic replacement and file sync. HawkEye formats a fixed leading template and writes directly. These guarantees differ; the comparison measures the stated tasks rather than equivalent feature sets. CPU limits and filesystem write costs can change the ranking.

An earlier control with the same binary hashes restricted both tools to one CPU: stale checks took 111.3 ms for LMH versus 74.9 ms for HawkEye, and repairs took 289.1 versus 121.9 ms. On the workspace overlay filesystem, 1,000-file repairs took 165.5 versus 38.6 ms; its backing hardware is unspecified. That earlier Python-based audit uses five timings and three RSS runs after warmup. See the CPU and storage results for all three tasks.

How much memory does it need?¶

Memory is peak native-process RSS, excluding the benchmark driver and compilation. Worker threads increase check memory; planning edits before allocating replacement bytes reduces repair memory compared with previous LMH.

All nine languages¶

LMH medians for a separate 1,000-file tree in each language:

Method and recorded environment¶

Recorded 2026-10-02 UTC from source 59c4782 versus previous source 8d72bf1 and locally built HawkEye 7.2.0. All use Rust 1.93.0 and locked release builds; LMH uses thin LTO, HawkEye its upstream release defaults. The shared runner is Linux x86_64, glibc 2.41, AMD EPYC 9V74. Fixtures use RAM-backed /tmp (tmpfs): 1 KiB/file, mixing all nine languages. These measurements cover the source CLI, rather than the published 0.6.0 wheel.

Five timings per case follow one discarded warmup. Bash measures wall time with millisecond precision; medians below 10 ms have limited resolution. Tool order rotates and reverses deterministically; every timing launches a fresh native CLI. Peak RSS is the maximum of five separate GNU time invocations on restored fixtures. Generation, restoration, validation and plotting stay outside timing. Each run verifies exit status, checked counts, findings and final source SHA-256 hashes. Both tools receive identical code statements, equal file counts/sizes, owner, license and years, using their accepted comment separators. HawkEye's Git attributes are disabled. Every findings/repair case has stale years in all files.

These are synthetic sources with warm filesystem caches and no persistent result cache. They are examples of workflow costs on one shared runner; results vary by hardware, file sizes, language mix and storage. Use your codebase's filesystem before estimating disk repair time.

Summary CSV · 10,000-file comparison samples · Versions, binary hashes and environment

Reproduce¶

From a checkout on Linux or macOS (Windows: WSL), install Git, the pinned Rust toolchain and a native linker. The driver uses Bash, jq, gnuplot and GNU time:

# Debian/Ubuntu
sudo apt install jq gnuplot-nox time
# macOS
brew install jq gnuplot gnu-time

cargo install hawkeye --version 7.2.0 --locked --root target/hawkeye
bash scripts/benchmark.sh --compare target/hawkeye/bin/hawkeye

The script builds the locked release CLI, measures all nine languages and mixed trees at 1, 100, 1,000 and 10,000 files, and writes CSVs, SVG/PNG charts and a standalone target/bench/report.html with embedded charts. Open that report to explore the slowdown for your workflow duration. Mixed cases below nine files are skipped.

To include the previous LMH implementation used in this snapshot:

git fetch origin 8d72bf1b81167a1e43e0e54e350e4e2351306bde
git worktree add --detach /tmp/lmh-baseline 8d72bf1
cargo build --release --locked --manifest-path /tmp/lmh-baseline/Cargo.toml --target-dir /tmp/lmh-baseline/target --bin lmh
bash scripts/benchmark.sh --baseline /tmp/lmh-baseline/target/release/lmh --compare target/hawkeye/bin/hawkeye

Use --files 1 100 --runs 3 for a quick run, --bytes 16384 for larger sources, or --binary /path/to/lmh for another native build. Set TMPDIR to an existing directory on your codebase's filesystem to include its write costs. On Linux, prefix the benchmark command with taskset -c CPU using one allowed CPU to compare both tools on one CPU. --help lists all options.

Charts and the archived report and data are browser uploads on PR #103. Only small CSVs and environment metadata live in Git. The benchmark workflow saves GitHub Actions artifacts. PR runs render committed data and include every CSV and JSON evidence file. Manual runs measure the full suite; the optional release tag selects an existing version. Actions artifacts expire. To keep results, download the artifact and upload it through the PR's browser uploader. Benchmark runs do not create releases or upload release assets.