Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
thanm opened this issue May 5, 2023 · 2 comments
Open

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

thanm opened this issue May 5, 2023 · 2 comments
Labels
FeatureRequest GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. ToolSpeed
Milestone
Backlog

Comments

@thanm
Copy link
Contributor

thanm commented May 5, 2023

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).
@thanm thanm added Performance NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. FeatureRequest GoCommand cmd/go labels May 5, 2023
@thanm thanm added this to the Backlog milestone May 5, 2023
@rsc
Copy link
Contributor

rsc commented May 5, 2023

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
Copy link
Contributor Author

thanm commented May 5, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
FeatureRequest GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. ToolSpeed
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
3 participants
@rsc @bcmills @thanm