Open
Description
What version of Go are you using (go version
)?
go1.10.2
Does this issue reproduce with the latest release?
Yes.
ijt$ time go1.11beta1 test .
ok github.com/google/go-cloud/wire/internal/wire 38.037s
real 1m10.576s
user 1m22.899s
sys 0m52.377s
ijt$ time go1.11beta1 test .
ok github.com/google/go-cloud/wire/internal/wire (cached)
real 0m30.822s
user 0m11.384s
sys 0m20.135s
What operating system and processor architecture are you using (go env
)?
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/issactrotts/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/issactrotts/gopath"
GORACE=""
GOROOT="/Users/issactrotts/homebrew/Cellar/go/1.10.2/libexec"
GOTMPDIR=""
GOTOOLDIR="/Users/issactrotts/homebrew/Cellar/go/1.10.2/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/9z/3vhqmj_j18v6vsk1q2jr486r001n0v/T/go-build330802734=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
m=github.com/google/go-cloud
go get $m
cd $(go list -f '{{.Dir}}' $m)
cd wire/internal/wire
# Run tests once.
time go test -v .
# Run tests again. This time the result is cached, but it still takes over 30s on a 2015 Macbook pro laptop.
time go test -v .
What did you expect to see?
The second test run should have taken under 1s since nothing changed.
What did you see instead?
It took over 30s.
@zombiezen suggested that the slowness arises from the wire tests opening many packages under $GOROOT
for type checking, making go test
spend a lot of time checking their hashes when deciding whether there is a cache hit.
Activity
mvdan commentedon Jul 31, 2018
Perhaps related to #26562.
ijt commentedon Jul 31, 2018
I ran it again like this
and the output seems to say that the same hashes are being recomputed many times.
It looks like the check could be sped up a lot by only computing the hashes once.
cmd/go: uniq test log lines in computeTestInputsID
gopherbot commentedon Aug 1, 2018
Change https://golang.org/cl/127155 mentions this issue:
cmd/go: check test cache more efficiently
ijt commentedon Aug 2, 2018
I instrumented
vgo test
and got this output fromgo tool pprof
:It shows that the
inDir
function takes up most of the time.ijt commentedon Aug 2, 2018
That lends support to the idea raised in issue #26562 that the slowdown was introduced in 37d5627.
ijt commentedon Aug 2, 2018
Simplifying
inDir
to no longer callEvalSymlinks
fixes the speed problem.The question is how to do it without giving up correctness.
mvdan commentedon Aug 2, 2018
The symlink issue is being fixed in #26562 already.
gopherbot commentedon Aug 2, 2018
Change https://golang.org/cl/127635 mentions this issue:
cmd/go: no longer eval symlinks in inDir
ijt commentedon Aug 2, 2018
Closing this as a duplicate of #26562.
cmd/go: no longer eval symlinks in inDir
25 remaining items