Some more information would be helpful.

Why concretely do you think it should only take seconds? Is the slow thing compiling the tests or executing the tests? Is 1.7.5 (or tip) faster?

Also, would you mind filing a separate issue about the line numbers, so that it doesn't get lost? Thanks.

I was using 1.7.5 and was used to the performance I had. When I downloaded 1.8.1 to replace 1.7.5, I notices vast performance drop: from some 12 seconds to about 3 minutes.

The slow thing is compiling. This is the command that executes slow:
$ go build --ldflags '-extldflags "-static"' -v .
Here is the output:

github.com/jmoiron/sqlx/reflectx
github.com/gorilla/mux
golang.org/x/net/context
github.com/op/go-logging
github.com/mattn/go-sqlite3
github.com/jmoiron/sqlx
_/mkk/wfrp3-data/almacen

The execution "halts" for almost 3 minutes after github.com/jmoiron/sqlx is printed and before _/mkk/wfrp3-data/almacen is printed. The presence of flags does not impact the performance, so the following command takes just the same time (~3 minutes) to execute.
go build -v .

PS. I'll file a separate issue about line numbers a bit later.

Please do a go install (instead of go build) and test again. Are the tests still slow?

Yeah, this is almost certainly because go build doesn't do any caching, which we have existing bugs open for. If you run go install or go test -i then subsequent builds will not have to rebuild all the dependencies. (This is not ARM-specific)

Ok. I had to copy "almacen" directory to under GOPATH. My GOPATH is /mkk/gopath, so the full application path is now /mkk/gopath/src/bitbucket.org/dertarr/wfrp3-data/almacen.
Executed the following (with the output) on version 1.8.1:

pi@raspberrypi:/mkk/gopath/src/bitbucket.org/dertarr/wfrp3-data/almacen $ go install -v .
github.com/gorilla/mux
github.com/op/go-logging
github.com/jmoiron/sqlx/reflectx
golang.org/x/net/context
github.com/mattn/go-sqlite3
github.com/jmoiron/sqlx
bitbucket.org/dertarr/wfrp3-data/almacen

It took 3 minutes to complete. Executing the same command for the second time takes almost no time. Then I updated a string literal inside my code and executed the command for the third time. The output is shorter, and the command completes in about 5 seconds, as it doesn't need to rebuild all libraries:

pi@raspberrypi:/mkk/gopath/src/bitbucket.org/dertarr/wfrp3-data/almacen $ go install -v .
bitbucket.org/dertarr/wfrp3-data/almacen

Then I switched to version 1.7.5. and deleted /mkk/gopath/pkg/linux_arm/github.com/jmoiron directory. Executed the command:

pi@raspberrypi:/mkk/gopath/src/bitbucket.org/dertarr/wfrp3-data/almacen $ go install -v .
github.com/gorilla/mux
golang.org/x/net/context
github.com/jmoiron/sqlx/reflectx
github.com/op/go-logging
github.com/mattn/go-sqlite3
github.com/jmoiron/sqlx
bitbucket.org/dertarr/wfrp3-data/almacen

It took the same 3 minutes to complete (it was rebuilding all libraries, not just the sqlx). I reverted the changes in the string literal and repeated go install -v . - the command completed in some 5 seconds.

So, the issue appeared in go build with version 1.8.1?

Sounds like this is just the build caching issue, which is known. The meta bug of sorts is #4719 which is partially about removing the need to "install" built deps and just always cache them. We've been making progress towards this over the past few releases, making the buildid in object files more inclusive. But more remains.

I'm going to close this issue. For now, keep in mind that you need to run go install or go test -i to install deps when switching versions if you want go build or go test to be fast.

Change https://golang.org/cl/75473 mentions this issue: cmd/go: cache built packages