Cap the number of cpus for Go compiles

When passing "-c" to the Go compiler, any time this value changes, we'd
force all of the Go compiles to rebuild. This could trigger a
substantial portion of the tree to rebuild (anything that transitive
depends on a Go helper tool).

We're running into issues when moving output directories between
multiple GCE machines with different core counts, but are otherwise
identical. This could also hit users moving/mounting disks between
machines, though changes to other host tools can make an impact too.

On my 48-core machine, I get a ~15% benefit from going from -c 1 to -c
48, but also ~12% benefit from going from -c 1 to -c 8. So this will
still let us scale somewhat, but prevent rebuilds when transitioning
between machines that are more likely building Android.
This commit is contained in:
Dan Willemsen 2018-03-02 15:03:24 -08:00
parent 774db4a8aa
commit 20c343b89e

View file

@ -39,7 +39,15 @@ var (
// Parallel compilation is only supported on >= go1.9
for _, r := range build.Default.ReleaseTags {
if r == "go1.9" {
return fmt.Sprintf("-c %d", runtime.NumCPU())
numCpu := runtime.NumCPU()
// This will cause us to recompile all go programs if the
// number of cpus changes. We don't get a lot of benefit from
// higher values, so cap this to make it cheaper to move trees
// between machines.
if numCpu > 8 {
numCpu = 8
}
return fmt.Sprintf("-c %d", numCpu)
}
}
return ""