Benchmarks: how fast alint is

By repository size

Two of the scenarios on synthetic trees from 1,000 to 1,000,000 files: S4, a workspace bundle with 85 rules, and S1, 16 layout and file-name rules. With --changed, alint checks only new files and files with unstaged changes, a tenth of the tree here.

Layout rules cost less than asking git what changed, so S1 is faster on the whole tree at every size. S4 reads file contents across the workspace, and many of its rules look across the whole tree, which --changed still checks in full. Since v0.21.0 the generated sources are clean, so a whole-tree run no longer reports a finding for every file, and from 100,000 files up --changed takes about as long as the whole tree. The --changed timings at 1,000 and 10,000 files are mostly the cost of waking the CPU's cores for a small job, so read them as rough.

A real tree: in May 2026, the 72 rules that didn't call other tools in the nixpkgs reference config, as it was then, checked a 52,354-file checkout in 332 ms (alint 0.9.17, 10 logical cores). The run is written up in the nixpkgs config's README.

Against scripts and other tools

On Kubernetes, some of alint's rules stand in for hack/verify-*.sh scripts. In May 2026, four of those scripts were timed against one alint pass on the same clone.

In April 2026, with alint 0.5.7, shell baselines and Repolinter were timed on one 100,000-file tree. On file names, eight find and grep pipelines took about four times as long as alint. On existence and content checks, a shell script using ripgrep was about as fast as alint, and Repolinter took about 14 times as long.

Ryzen 9 3900X, hyperfine with 3 warm-up runs and 10 measured runs, April 2026. These runs predate the engine work in v0.9 and haven't been repeated; the raw results are in the alint repository. The same run timed ls-lint 2.2.3, and that timing was wrong: the harness started ls-lint from a directory without its config, so it stopped before checking anything. ls-lint hasn't been timed again, and MegaLinter, which runs other linters in containers, hasn't been timed at all. Compare covers what each tool checks.

Release by release

Every benchmarked release records full-check timings for S1 to S4 on the million-file tree (S3 from v0.12.0 on). Starting with v0.17.0, it also records SFIX, the dry-run auto-fix pass. Within one workload revision, each scenario ended close to where it started: S1 +2%, S2 0%, S3 +3%, S4 +3% and SFIX +7% from v0.21.0 to v0.22.0. No release in between moved more than 10%. SFIX is a release snapshot: when its fixable-rule set changes, its timing changes with the workload as well as the engine. The releases before this machine became the benchmark host, in July 2026, were timed on it afterwards with the same harness.

SFIX is not available before v0.17.0, when alint fix was introduced. Releases without a retained macro-benchmark record, including v0.16.1 and v0.18.3, have no row. The other sizes and scenarios for each release are in HISTORY.md.

Before v0.17, this series used 14 check scenarios; v0.17 consolidated those to S1 through S4 and added SFIX. The earlier releases in the table were re-measured for S1 through S4 with the new harness; their binaries predate alint fix, so SFIX cannot be run for them. The 14-scenario numbers are frozen in the legacy history.

S4's workload is revisioned separately: v0.19.0 expanded it from 50 to 85 resolved rules by adding the versioning and toolchain-pins bundles. Its v0.19.0 timing is the revision-2 baseline, not a like-for-like regression against earlier S4 rows. Revision 2's tree had none of the version and toolchain files those bundles look for, so their rules never applied. v0.20.0's revision 3 commits those files, and 82 of the 85 rules now apply. Its S4 timing is the revision-3 baseline. v0.20.0 also made exact-path facts cheaper, so the change from v0.19.0 mixes workload and engine.

v0.21.0 moved every scenario to a new workload revision: S1 to S3 and SFIX to revision 2, S4 to revision 4. The generated Rust, JavaScript and Python sources now end with a newline, and none of their lines starts or ends with a space. Before, S2's final-newline rule reported a finding for every generated source and its whitespace rules tens of thousands more, about 86,000 findings at 100,000 files, so S2 timed findings as much as linting. Most of the drops at a million files, S2's from 18.2 s to 5.30 s and S4's from 15.6 s to 8.61 s, come from the cleaner tree. On the same clean tree, v0.21.0's code ran S2 8.6% faster than v0.20.1, because the Rust import check now skips a file without use, and S4 about 1% faster, in measurements of pre-release builds rather than the recorded runs. SFIX's drop, from 54.4 s to 35.3 s, was not measured on one tree, so it is not split between the two. The v0.21.0 row is the new baseline for every scenario.

Before this machine, the benchmarks ran on a Ryzen 9 3900X desktop, from v0.5.6 to v0.13.0. That series recorded the two engine fixes that made the million-file tree fast: S3 went from 731.9 s in v0.9.4 to 12.59 s in v0.9.5, and S7 from 614.4 s in v0.9.7 to 15.41 s in v0.9.8. The whole series is in HISTORY.md as it stood before the move to this machine; its numbers don't compare with this machine's.

The scenarios

Each scenario is one config file in the alint repository, run against a generated Cargo-workspace tree. S4 uses a polyglot tree with Rust, Node and Python packages, made into a git repository; S3 builds file graphs across it; SFIX is the one scenario timed in fix mode.

S3 is much slower than the rest: 47.9 s on 100,000 files and 8 min 10 s on 1,000,000 in v0.22.0, because it builds a graph over the whole tree on every run. The scenario catalog says which part of the engine each exercises; the config files have the detail.

How the numbers are made

• hyperfine times the alint binary from outside the process, so startup, file-system calls and output all count, the way you'd run it.
• The trees come from a fixed seed (0xA11E47) and are the same on every run: 1,001, 10,001, 100,001 and 1,000,001 files. With 4 check scenarios at 4 sizes and 2 modes, plus the auto-fix scenario at 4 sizes, that's 36 timings per release.
• The alint repository also has criterion micro-benchmarks that time the CPU-bound parts separately: glob and regex matching, the rule engine, the walker, the output formats.

The methodology explains why the tables here use means while the release check compares minimum times.

Catching regressions

The investigation has the numbers, including the step that first blamed the benchmark setup.