alint benchmarks

What we publish, and how often

• 13 macro scenarios (S1–S13) driven by hyperfine, run at 4 sizes (1k / 10k / 100k / 1M files) in two modes (full all-files scan and changed via --changed). That's 104 (scenario, mode, size) cells per release. S10 added in v0.9.9 (out-of-per-file-dispatch scope_filter:); S11–S13 added in v0.10 to cover the new cross-file / per-file / single-shot dispatch classes.
• 12 micro benches (criterion) covering pure-CPU primitives: glob compile, regex content scans, engine fan-out, walker, formatters. Floor-tested vs an earlier same-host baseline on every PR; anything >10 % slower fails CI.
• Per release. Numbers regenerate via the bench-record.yml workflow on a self-hosted runner with a known hardware fingerprint, then land in docs/benchmarks/HISTORY.md (the canonical source of truth this page summarises).

Real-world: NixOS/nixpkgs

The largest non-trivial OSS monorepo on GitHub, used as a real-world stress beyond the synthetic 100K bench. The 79-rule pass includes a for_each_dir over the 20,678-directory pkgs/by-name/*/*/ tree, exactly the cross-file dispatch shape the v0.9.5 + v0.9.6 + v0.9.8 engine work was designed to make linear.

A real-world complement to the synthetic matrix, measured on the 3900X reference desktop (the case study predates the kbench re-baseline), not a like-for-like kbench cell.

Full nixpkgs case study →

Synthetic: per-release trajectory

1M-file headline cells across the most-stressed scenarios, on the current kbench series. S3 is the realistic-monorepo anchor; S6 is the per-file content fan-out; S7 is the cross-file relational path; S9 is the nested-polyglot scenario the scope_filter: primitive exists for. The trajectory is flat by design; the dramatic v0.9 engine cliffs are on the retired 3900X series.

This kbench series is deliberately flat: from v0.10 through the latest release, performance holds steady while the rule surface grew. The dramatic engine cliffs (S3 731.9 s → 12.59 s at v0.9.5; S7 614.4 s → 15.41 s at v0.9.8), each with an investigation write-up, are on the retired 3900X series. See investigations/ for the diagnostic write-ups.

Full per-release table (S1–S13, all sizes, both modes) →

What each scenario stresses

Methodology, short version

Two layers. criterion for pure-CPU micro-benchmarks (stable, cross-platform, run on every PR). hyperfine driven by xtask bench-scale for end-to-end CLI wall-time (cross-platform, reproducible, honest about variance, run before each release tag).

Three deliberate methodology choices:

• Hyperfine, not a custom Rust harness. Hyperfine measures wall-time of an external command from outside the process: exactly the cost shape a CLI user pays, including process startup, dynamic linker overhead, stdio buffering, format selection. A Rust-internal harness would skip those and overstate alint's speed.
• Deterministic synthetic monorepo, not a real-world repo for cross-version comparison. Synthetic trees are byte-identical across machines given the same seed (0xA11E47): 1k = 1,001 files exactly, 1M = 1,000,001 files exactly, no tree-size drift contaminating cross-version comparisons. The nixpkgs data point above is the non-synthetic complement.
• Not CodSpeed / iai-callgrind. Both are Valgrind- based; alint's hot path is syscall-heavy (the ignore-crate walk), and Valgrind's instruction counts drift whenever the CI runner's glibc or kernel updates, exactly the part of alint we most want stable numbers for.

Full methodology document →

Honest comparisons

Mostly we don't have apples-to-apples public benches, because the other tools haven't published any.

• vs Repolinter. No public benches exist; Repolinter was archived 2026-02. Architectural shape (Node startup ~100 ms + per-rule JS execution) suggests 1–2 orders of magnitude slower at 100K files, but that's an estimate, not a measurement.
• vs ls-lint. No public benches at scale. ls-lint is a Go binary doing filename + directory matching only: narrower scope, likely faster than alint at S1's specific shape. If filename conventions are the only thing you care about, ls-lint will likely be faster.
• vs Megalinter. Shape-mismatch comparison. Megalinter is a Docker orchestrator, not a linter. Its wall-time is dominated by container startup + per-tool execution, not by any single tool's hot path. Use Megalinter alongside alint, not instead of.
• vs custom shell scripts. Each repo's verify-*.sh directory is bespoke; the wall-time comparison doesn't generalise. The kubernetes case study replaced 17 of 50 verify scripts with one alint config; the win shows up in CI wall-time variance more than in raw speed.

See /compare/ for the full feature-matrix comparison.