Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Is this a partial build using cmd/compile? Or a typechecking via go/packages or go/types? (Sorry, I haven't tracked any of the recent changes.) If the former, I don't see why the regular compilebench benchmarks don't cover it. If the latter, I don't think compilebench is the right home for it, since it is about cmd/compile. Similarly, if the question is about vet performance once the partial build is complete, I don't think compilebench is the right home.
I definitely agree that we should track this performance. It's just a question of where and how.
Worth noting that the same compilation is required for vet and for actually compiling and linking the test, so adding in vet isn't actually much of a change here.
@josharian: the new analysis tools in x/tools may run in two modes: "above" the build system, using x/tools/go/packages (implemented by multichecker), or "below" the build system, through "go vet -vettool" (implemented by unitchecker). The cmd/vet in GOROOT works only in the latter mode, to avoid depending on multichecker and thence go/packages. The command 'go vet p' compiles everything package p depends on, but not p itself. I agree there's no obvious way to separate the contributions of cmd/compile and cmd/vet to the time of go vet. It seems as hard as the usual problem of measuring the critical path contribution of some task in a parallel build.
@bcmills I don't think it's a 1.12 blocker. I don't have a good sense of where this benchmark belongs; I filed the issue at Russ's request.