Performance

v7 against v6.2.0, on a 2,000-project repository

6.5× faster

727s at v6.2.0 against 111s at v7. At 250 projects it is 1.3× — the gap widens with repository size.

Every figure on this page compares v7 against v6.2.0, the last v6 release, over identical generated repositories. The larger the repository, the more v7 saves — which is the point worth taking from this page, since large repositories are what this tool is for.

How much fasterSpeedup over v6.2.0, by repository size. Higher is better.

Wall clock per runMean of the measured iterations. The axis is logarithmic — each gridline is ten times the last.

Row labels are total projects. Exact numbers, spread and iteration counts are in the table below.

The numbers

Projects	Graph nodes	v6.2.0	v7	Change	Speedup	Iterations
250	1,000	7.80s± 6.28%	5.90s± 7.29%	-24.4%	1.32×	10
500	2,000	17.1s± 2.57%	10.9s± 2.12%	-36.4%	1.57×	10
1,000	4,000	79.9s± 1.95%	28.1s± 2.42%	-64.8%	2.84×	10
2,000	8,000	727s± 1.41%	111s± 4.4%	-84.7%	6.52×	5

Both versions produced the same affected projects at every size, so this is not one of them doing less work: the run at 2,000 projects reports 1,994 affected out of 2,000.

Why it scales better

Cost growth per doubling, as an exponent: 1 is linear, 2 quadratic, 3 cubic.

Step	v6.2.0	v7
250 → 500	1.132	0.882
500 → 1,000	2.225	1.371
1,000 → 2,000	3.185	1.986

v6’s cost climbs from roughly linear to worse than quadratic as the repository grows. v7’s stays under 2 across the same range. Neither exponent is constant, so neither should be extrapolated past the largest size measured.

How this was measured

These are desktop numbers

They were produced on an unloaded desktop, not a CI runner, and they are comparable to each other and to nothing else. Both sides were built with the same SDK, resolve the same MSBuild, and each pair ran interleaved against one generated repository. Absolute figures on your hardware will differ; the ratio is the transferable part.

Baseline	v6.2.0 (a88f3d63)
Candidate	main (699ebb47)
Invocation	dotnet-affected -p <repo> --dry-run --format text
Repository shape	Generated csproj tree, 20 children per project, one added .cs file in every fifth project, committed clean then dirtied.
CPU	AMD Ryzen 7 PRO 8840U w/ Radeon 780M Graphics
OS	fedora 44, Linux 7.1.5-201.fc44.x86_64 x86_64
.NET SDK	10.0.201
MSBuild	18.3.0-release-26153-122+4d3023de6
Configuration	Release

Measurement is at the process level: the executables are run and timed, so startup and MSBuild load count, which is what a user actually waits for. One warmup run per version is discarded, and the two versions alternate so drift affects both equally.

Part of v7’s gain comes from discovery no longer walking .git or gitignored paths, not only from the graph work. The BenchmarkDotNet suites run on every push to main and isolate the algorithm from discovery; this page is the end-to-end view.

Reproducing the whole comparison takes about 1.9 hours of wall clock, most of it spent on the baseline at the largest size.

Data

Every figure here is generated from a JSON snapshot committed alongside the site, one per release, under docs/src/data/benchmarks/. The snapshots hold the raw per-iteration timings where they were captured, and every derived field — change, speedup, cost ratio, exponent — is computed rather than transcribed. Snapshots are never regenerated: a published comparison that changes underneath a reader is not a comparison.

v7.0.0 is the first release with a published comparison.