cmd/go: decouple cmd/cover action from build action for "go {build,test} -cover"

[thanm]

This is a feature request issue to track an idea for speeding up "go test -cover" and "go build -cover" slightly in the case where we're building multiple packages.

Currently the "go tool cover" invocation for a given package is lumped into the build action, e.g. the single action invokes first "go tool cover" and then "go tool compile". It might be more efficient to break out the "go tool cover" invocation into its own separate action, then make the build action dependent on that action.

The advantage here is that the "cover" action doesn't have to wait on any of the build action's dependencies (the compiler needs the deps, but the cover tool does not). This would result in increased parallelism in the build and would help speed things up somewhat (subject to constraints on number of packages, number of processors, etc).

[rsc]

The overall approach in the go command is to have an action graph that splits up enough work to get decent parallelization but not more. As you split up the work beyond "decent parallelization" you end up with more work to track, larger build graphs to keep in memory, more intermediate artifacts to store in the on-disk cache, and so on.

It would be good to have a clearer estimate of the win here before taking on the complexity of splitting up the compile step further. At least in the old days, the cover rewriting part was essentially free compared to the compile+link, so the win would have been minimal. Perhaps cover has more expensive, enough to be worth splitting off, or perhaps the compiler has gotten less expensive, but perhaps not.

[thanm]

Thanks Russ, so noted. I agree that it would be worth prototyping / benchmarking. If it doesn't show a decent gain, no point in doing it. FWIW I don't think that cmd/cover markedly sped up or slowed down during the coverage rewrite.