Benchmark the init cost of Go packages
BSD-3-CLAUSE License
Benchmark the initialization cost of your packages or programs. Requires Go 1.22 or later.
go install mvdan.cc/benchinit@latest
This includes the cost of init
functions and initialising globals.
In other words, a package's contribution to the slowness before main
is run.
Benchmarking a single package is simple:
benchinit cmd/go
You can benchmark multiple packages too; there must be at most one main package:
benchinit cmd/go go/parser go/build
You can also include all dependencies in the benchmark:
benchinit -r cmd/go
Finally, like any other benchmark, you can pass in go test
flags:
benchinit -r -count=5 -benchtime=2s cmd/go
The original tool was result of a discussion with @josharian.
You can read more about Josh's idea in his blog post.
Since then, GODEBUG=inittrace=1
was added in Go 1.16,
which this tool now uses.
The following design decisions were made:
GODEBUG=inittrace=1
requires us to run a new Go process for every benchmark
iteration, so benchinit
sets up a wrapping benchmark BenchmarkInit
which
does this and collects the inittrace
output. BenchmarkInit
then produces
one BenchmarkPkgPath
result per package passed to benchinit
, which is
shown to the user.
benchinit
supports most build and test flags, which are passed down as
needed. For example, you can use -benchtime
and -count
to control how the
benchmark is run, and -tags
to use build tags. Note that some test flags
like -bench
aren't supported, as we always run only BenchmarkInit
.
To avoid building a new binary, BenchmarkInit
reuses its own test binary to
run the Go process for each benchmark iteration. To prevent test globals and
init
funcs from being part of the result, all *_test.go
files are masked
as deleted via -overlay
. The same overlay is used to insert a temporary file
containing BenchmarkInit
.
BenchmarkInit
only runs one Go process per benchmark iteration, even when
benchmarking multiple packages at once. This is possible since inittrace
prints one line per package being initialized, so we only need to ensure
the test binary imports all the necessary packages to initialize them.
For the same reason, we can only benchmark one main
package at a time.
If none of the given packages are a main
package, the benchmark is run from
the first given package. This helps us support benchmarking internal packages.