benchinit

Benchmark the initialization cost of your packages or programs. Requires Go 1.18 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.

Quickstart

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

Further reading

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.