Benchmarks

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

Measured on 2026-08-31 at commit 8ab940b289ba, by the release that published this site.

This release measured 32 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.

By module

pkg/ccme

linux/amd64, AMD EPYC 7763 64-Core Processor

Benchmark	Time/op	Bytes/op	Allocs/op	Iterations
BenchmarkNormalizeRewrite	794.5 ns	240 B	1	1,297,449
BenchmarkParseDirectives	14.2 µs	2.5 KiB	16	134,010
BenchmarkParseInvalid	5.9 µs	1.3 KiB	14	260,913
BenchmarkParseSimple	5.6 µs	1.2 KiB	5	297,630
BenchmarkParseSubject	3.8 µs	832 B	2	677,516

pkg/config

linux/amd64, AMD EPYC 7763 64-Core Processor

Benchmark	Time/op	Bytes/op	Allocs/op	Iterations
BenchmarkApplyEdits/json	1.6 ms	13.4 KiB	118	772
BenchmarkApplyEdits/yaml	2.3 ms	404.1 KiB	1,891	541
BenchmarkDecode/full	164.9 µs	28.4 KiB	514	8,535
BenchmarkFold/lower	13.59 ns	0 B	0	83,989,353
BenchmarkFold/mixed	73.90 ns	8 B	1	18,577,078
BenchmarkFold/unicode	242.1 ns	16 B	1	5,453,582
BenchmarkReadTree/json/large	12.8 ms	413.0 KiB	5,635	100
BenchmarkReadTree/json/medium	326.6 µs	32.1 KiB	582	7,861
BenchmarkReadTree/json/small	25.9 µs	3.6 KiB	72	42,118
BenchmarkReadTree/toml/large	11.3 ms	681.7 KiB	8,624	126
BenchmarkReadTree/toml/medium	427.5 µs	54.7 KiB	882	3,463
BenchmarkReadTree/yaml/medium	1.0 ms	106.9 KiB	1,999	1,431
BenchmarkReadTree/yaml/small	109.3 µs	16.8 KiB	244	11,781
BenchmarkRefDepth/1	40.1 µs	4.9 KiB	93	45,984
BenchmarkRefDepth/32	304.7 µs	50.9 KiB	692	6,402
BenchmarkRefDepth/8	115.0 µs	15.1 KiB	232	10,000
BenchmarkRefWidth/2	23.6 µs	3.6 KiB	58	67,412
BenchmarkResolve/16	302.5 µs	17.8 KiB	174	3,759
BenchmarkResolve/4	106.4 µs	7.0 KiB	76	10,000
BenchmarkSettings/dotted	263.6 µs	76.9 KiB	505	7,558
BenchmarkSettings/empty-objects	83.2 µs	6.6 KiB	5	15,628
BenchmarkSettings/flat	58.8 µs	6.6 KiB	5	29,368
BenchmarkSettings/nested	77.4 µs	11.7 KiB	65	17,619

services/dispat

linux/amd64, AMD EPYC 7763 64-Core Processor

Benchmark	Time/op	Bytes/op	Allocs/op	Iterations
BenchmarkComputeGroup/fixed	3.6 ms	560.4 KiB	3,416	316
BenchmarkComputeGroup/fixedMajor	3.8 ms	562.7 KiB	3,414	295
BenchmarkComputeGroup/fixedMajorMinor	3.3 ms	562.7 KiB	3,413	366
BenchmarkComputeGroup/fixedSparse	2.7 ms	459.3 KiB	2,198	397

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 — a budget with 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
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
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 — the inputs earlier fuzzing sessions found interesting, 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.