Benchmarks

What the code costs, as opposed to what it does and what the suite reached.

Measured on 2026-09-25 at commit 374e6469e43c, by the release that published this site.

This release measured 91 benchmarks across 3 modules, on linux/amd64, AMD EPYC 7763 64-Core Processor.

Every number on this page is measured rather than written. A benchmark pass runs go test -run '^$' -bench . -benchmem per module, in a stage of its own, and the release folds the stream into the same report the coverage and test-results pages read. Nothing here is a figure someone typed into a document, which matters more for a performance claim than for almost any other kind: a benchmark number written by hand is a number about a machine that no longer exists.

-run '^$' is not optional. Without it every test runs again alongside the benchmarks, and the timings become numbers about a machine that was busy doing something else. -benchtime is left at Go's own default, because a measurement taken over fewer iterations than the tool chose is a measurement nobody can compare.

The benchmark stages are cached by the module source, workspace providers and reporting tool they contain. A docs-only commit reuses the identical stream; a source, dependency or harness change runs the benchmark again. The report names the publishing commit while retaining the runner and timestamp recorded by the actual benchmark process.

By module

pkg/ccme

linux/amd64, AMD EPYC 7763 64-Core Processor

Benchmark	Time/op	Bytes/op	Allocs/op	Iterations
BenchmarkNormalizeFastPath	102.3 ns	0 B	0	17,484,582
BenchmarkNormalizeRewrite	742.6 ns	240 B	1	1,634,053
BenchmarkParseCRLF	4.7 µs	1.2 KiB	5	243,950
BenchmarkParseDirectives	25.3 µs	2.5 KiB	16	82,282
BenchmarkParseHistory	36.4 µs	9.5 KiB	42	32,644
BenchmarkParseInvalid	7.6 µs	1.3 KiB	14	153,630
BenchmarkParseMultiUnit	13.2 µs	3.8 KiB	12	127,032
BenchmarkParseParallel	9.2 µs	2.5 KiB	16	133,777
BenchmarkParseSimple	6.9 µs	1.2 KiB	5	338,930
BenchmarkParseSubject	3.6 µs	832 B	2	588,780

pkg/config

linux/amd64, AMD EPYC 7763 64-Core Processor

Benchmark	Time/op	Bytes/op	Allocs/op	Iterations
BenchmarkApplyEdits/json	1.5 ms	18.7 KiB	134	690
BenchmarkApplyEdits/yaml	3.8 ms	407.7 KiB	1,905	495
BenchmarkDecode/fold-hit	152.3 µs	28.5 KiB	540	10,000
BenchmarkDecode/full	163.2 µs	28.4 KiB	514	7,282
BenchmarkDecode/small	5.1 µs	1.0 KiB	22	254,648
BenchmarkEnvBinding	38.7 µs	6.9 KiB	135	37,027
BenchmarkFold/lower	15.94 ns	0 B	0	73,443,444
BenchmarkFold/mixed	199.0 ns	8 B	1	11,018,461
BenchmarkFold/unicode	505.8 ns	16 B	1	2,520,537
BenchmarkLoad	151.5 µs	20.3 KiB	265	12,180
BenchmarkOverrides	63.7 µs	12.2 KiB	72	18,942
BenchmarkReadTree/json/large	2.8 ms	413.0 KiB	5,635	583
BenchmarkReadTree/json/medium	244.9 µs	32.1 KiB	582	7,784
BenchmarkReadTree/json/small	35.0 µs	3.6 KiB	72	31,282
BenchmarkReadTree/toml/large	8.3 ms	681.7 KiB	8,624	145
BenchmarkReadTree/toml/medium	406.0 µs	54.7 KiB	882	3,462
BenchmarkReadTree/toml/small	39.8 µs	6.6 KiB	108	27,350
BenchmarkReadTree/yaml/large	16.5 ms	1.1 MiB	19,626	100
BenchmarkReadTree/yaml/medium	973.3 µs	106.9 KiB	1,999	1,416
BenchmarkReadTree/yaml/small	133.0 µs	16.8 KiB	244	10,000
BenchmarkRefDepth/1	67.4 µs	4.9 KiB	93	45,309
BenchmarkRefDepth/32	276.3 µs	50.9 KiB	692	6,508
BenchmarkRefDepth/8	142.0 µs	15.1 KiB	232	10,000
BenchmarkRefWidth/2	19.5 µs	3.6 KiB	58	59,533
BenchmarkRefWidth/32	451.6 µs	41.8 KiB	635	5,061
BenchmarkRefWidth/8	82.6 µs	10.9 KiB	173	15,116
BenchmarkResolve/1	54.9 µs	4.8 KiB	52	25,383
BenchmarkResolve/16	337.3 µs	17.8 KiB	174	3,674
BenchmarkResolve/4	172.6 µs	7.0 KiB	76	5,832
BenchmarkSettings/dotted	281.8 µs	76.9 KiB	505	7,228
BenchmarkSettings/empty-objects	56.8 µs	6.6 KiB	5	20,469
BenchmarkSettings/flat	68.3 µs	6.6 KiB	5	28,621
BenchmarkSettings/nested	73.3 µs	11.7 KiB	65	19,395

services/dispat

linux/amd64, AMD EPYC 7763 64-Core Processor

Benchmark	Time/op	Bytes/op	Allocs/op	Iterations
BenchmarkPolyrepoInitialVersionIndexes/100	215.2 µs	39.7 KiB	226	5,910
BenchmarkPolyrepoInitialVersionIndexes/1000	3.9 ms	670.2 KiB	2,050	477
BenchmarkPolyrepoInitialVersionIndexes/10000	18.4 ms	5.3 MiB	20,196	57
BenchmarkPrintErrorDiagnostics	70.3 µs	0 B	0	28,015
BenchmarkSetSnapshotPlanRepositoryClosures	484.5 µs	72.8 KiB	26	3,421
BenchmarkSettleLinksExactFastPath	2086.3 ms	33.2 KiB	322	1
BenchmarkValidatePackageOwnership/100	2.5 ms	148.3 KiB	1,613	590
BenchmarkValidatePackageOwnership/1000	33.9 ms	1.5 MiB	16,024	63
BenchmarkValidatePackageOwnership/10000	347.3 ms	15.1 MiB	160,084	3
BenchmarkFirstSnapshotToTwoNodes	532.1 ms	30.0 KiB	261	3
BenchmarkParseCommits	275.5 ms	72.3 MiB	400,031	9
BenchmarkParseControlGitlinkHistory	124.6 ms	41.0 MiB	380,022	14
BenchmarkParseTagsForPackagesIndexed/overlapping_custom_formats/indexed	8.8 ms	985.3 KiB	8,919	165
BenchmarkParseTagsForPackagesIndexed/overlapping_custom_formats/per_package_scan	16.9 ms	967.4 KiB	8,900	78
BenchmarkParseTagsForPackagesIndexed/standard_prefixes/indexed	22.3 ms	6.6 MiB	71,022	61
BenchmarkParseTagsForPackagesIndexed/standard_prefixes/per_package_scan	1095.1 ms	6.5 MiB	71,172	2
BenchmarkComputeChainTopology/packages=1024	296.8 ms	195.1 MiB	632,357	4
BenchmarkComputeChainTopology/packages=4096	4413.6 ms	3277.6 MiB	8,937,301	1
BenchmarkComputeComposedSharedHistory	46.1 ms	16.2 MiB	26,749	22
BenchmarkComputeDependencyGraph/packages=1024	15.0 ms	8.7 MiB	41,036	86
BenchmarkComputeDependencyGraph/packages=256	4.0 ms	1.9 MiB	10,436	277
BenchmarkComputeDependencyGraph/packages=4096	65.8 ms	38.8 MiB	163,585	21
BenchmarkComputeFleetSnapshot/repositories=16/packages=256	27.2 ms	12.8 MiB	118,866	45
BenchmarkComputeFleetSnapshot/repositories=4/packages=64	7.3 ms	3.4 MiB	32,912	165
BenchmarkComputeGroup/fixed	5.7 ms	803.9 KiB	5,304	236
BenchmarkComputeGroup/fixedMajor	4.0 ms	807.0 KiB	5,304	325
BenchmarkComputeGroup/fixedMajorMinor	4.2 ms	807.1 KiB	5,304	304
BenchmarkComputeGroup/fixedMajorSparse	4.0 ms	689.9 KiB	3,689	374
BenchmarkComputeGroup/fixedSparse	3.7 ms	689.9 KiB	3,689	304
BenchmarkComputeRealHistory/shape=bounded/commits=10000	396.9 ms	15.7 MiB	76,319	3
BenchmarkComputeRealHistory/shape=bounded/commits=50000	1469.6 ms	83.5 MiB	359,829	1
BenchmarkComputeRealHistory/shape=composed/commits=10000	603.7 ms	34.3 MiB	205,417	2
BenchmarkComputeRealHistory/shape=composed/commits=50000	2528.4 ms	183.4 MiB	1,083,403	1
BenchmarkComputeRealHistory/shape=whole/commits=10000	752.7 ms	46.5 MiB	273,213	2
BenchmarkComputeRealHistory/shape=whole/commits=50000	3250.0 ms	227.2 MiB	1,321,698	1
BenchmarkComputeSharedHistory/packages=128	4.0 ms	1.9 MiB	12,451	279
BenchmarkComputeSharedHistory/packages=512	7.3 ms	3.2 MiB	18,239	168
BenchmarkComputeTagInventory/packages=256/versions=16	4.1 ms	2.8 MiB	9,813	321
BenchmarkComputeTagInventory/packages=512/versions=8	4.5 ms	2.4 MiB	12,385	254
BenchmarkComputeVersionGroups/groups=16/members=16	1.7 ms	1.0 MiB	5,613	661
BenchmarkComputeVersionGroups/groups=64/members=16	7.5 ms	4.3 MiB	21,598	156
BenchmarkControlCheckpointPersistentSnapshots	1.1 ms	452.4 KiB	8,032	1,008
BenchmarkControlWindows	42.7 ms	11.8 MiB	80,264	26
BenchmarkLinkBoundaryChain/repositories=2/depth=1	109.4 µs	43.5 KiB	422	10,000
BenchmarkLinkBoundaryChain/repositories=4/depth=3	203.0 µs	73.7 KiB	813	5,757
BenchmarkLinkBoundaryChain/repositories=8/depth=7	442.1 µs	138.9 KiB	1,671	2,486
BenchmarkReleaseRepositoryInputs	973.2 µs	424.4 KiB	4,976	1,230
BenchmarkCreateReleaseTags	126.2 ms	695.1 KiB	7,666	8

A row is one benchmark function, or one case of a table-driven one, named as its source names it. The iteration count is a column rather than a footnote because it is what says how much to trust the row beside it: a benchmark the tool ran ten times and one it ran ten million times are not the same kind of number. The machine is stated per module for the same reason. A nanosecond figure without the CPU that produced it is a number nobody can compare anything to, and a release runner is not a workstation.

Allocations are the figure to read first. A time depends on the machine, the toolchain and whatever else was running; an allocation count is a property of the code, and it moves only when someone changes what the code does. That is why several of these packages pin their allocation counts as tests, with a budget that has one allocation of headroom, so a toolchain change does not fail a build for a rounding difference while a reintroduced copy fails it immediately.

Fuzz targets

Target	Package	Corpus entries
FuzzNormalize	pkg/ccme	114
FuzzParse	pkg/ccme	116
FuzzParseSubject	pkg/ccme	114
FuzzParsers	pkg/config	9
FuzzRefTargets	pkg/config	8
FuzzSettings	pkg/config	5
FuzzGradleLine	pkg/scanner	16
FuzzPBXSetting	pkg/scanner	9
FuzzParseAquaBounded	pkg/scanner	1
FuzzParsers	pkg/scanner	39
FuzzPep508Dep	pkg/scanner	8
FuzzPodDeclaration	pkg/scanner	12
FuzzPodspecStatement	pkg/scanner	10
FuzzLink	pkg/writer	12
FuzzReplaceBytes	pkg/writer	8
FuzzRewriteAndroidManifest	pkg/writer	7
FuzzRewriteAquaNeverCommitsInvalidYAML	pkg/writer	3
FuzzRewriteCargo	pkg/writer	8
FuzzRewriteCompose	pkg/writer	9
FuzzRewriteComposer	pkg/writer	6
FuzzRewriteCsproj	pkg/writer	6
FuzzRewriteDockerfile	pkg/writer	9
FuzzRewriteGemfile	pkg/writer	6
FuzzRewriteGodotCfg	pkg/writer	10
FuzzRewriteGradleBuild	pkg/writer	8
FuzzRewriteGradleCatalog	pkg/writer	8
FuzzRewriteMaven	pkg/writer	7
FuzzRewriteNpm	pkg/writer	8
FuzzRewriteNuGetLists	pkg/writer	6
FuzzRewriteNuspec	pkg/writer	6
FuzzRewritePlist	pkg/writer	8
FuzzRewritePodfile	pkg/writer	8
FuzzRewritePubspec	pkg/writer	6
FuzzRewritePyproject	pkg/writer	9
FuzzRewriteUPlugin	pkg/writer	8
FuzzRewriteUnityProjectSettings	pkg/writer	8
FuzzRewriteXcodeProj	pkg/writer	7

A fuzz target under a plain go test runs its corpus rather than fuzzing: the seeds the test declares with f.Add, plus whatever testdata/fuzz holds for it: inputs earlier fuzzing sessions found interesting and kept as regression cases. The corpus column is what every suite run exercises, and it is the honest half of the number. It is not a claim that a fuzzing session ran here, because none did.

Fuzzing itself is a thing somebody does on purpose, for as long as they have:

go test ./... -run '^$' -fuzz FuzzParse -fuzztime 10m

A crash it finds is written into testdata/fuzz as a new corpus entry, committed, and from then on every run of the ordinary suite replays it. That is why the corpus grows and why the count above is worth reading: it is the number of inputs the suite is holding the parsers to, not the number of inputs anyone has tried.

Reproducing

The whole measurement is one command per module from the monorepo root, and it is the one the release runs:

go run github.com/yohimik/dispat/tools/testreport bench config -- ./... -run '^$' -bench . -benchmem
go run github.com/yohimik/dispat/tools/testreport build   # writes packages/docs/data/report.json, read by this page

The stream lands in coverage/benchlog/<module>.json, beside the go test -json logs the suites leave in coverage/testlog/. A module measured by a run replaces whatever it had; a module the run did not measure keeps it, so a release that rebuilt only part of the monorepo does not blank a page. Rebuilding this site with packages/docs/data/report.json in place is what puts the figures back; without one, the prose stays and the tables are left out.

What a benchmark here is for

These are regression gates, not marketing. A benchmark exists in this repository when there is a specific mistake it would catch: a second deep copy of a parsed document, a flat intermediate map materialised only to be rebuilt, a per-element allocation in a loop that could have hoisted it. The corresponding allocation budget is what turns the benchmark into a gate. The benchmark says what it costs, and the budget fails the build when the cost changes for a reason nobody intended.

What none of them are is a comparison against another library. A benchmark measuring two things measures the harness between them, and this repository has no honest way to run somebody else's code on the same terms.