go 命令在我的 Windows 机器上运行缓慢，在我的 linux 上运行良好

Question

I don't know if someone else is running into this problem. I have this main.go file:

package main

import "fmt"

func main() {
    fmt.Println("hello world")
}

when I run go build, it takes 5 secs to run it (regardless if it is the first time I run it or if it is the second time)

PS> Measure-Command {Start-Process go build -wait}

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 5
Milliseconds      : 151
Ticks             : 51514117
TotalDays         : 5.96228206018519E-05
TotalHours        : 0.00143094769444444
TotalMinutes      : 0.0858568616666667
TotalSeconds      : 5.1514117
TotalMilliseconds : 5151.4117

But when I run it on a linux machine:

time go build

real    0m2.017s
user    0m0.054s
sys     0m1.915s

and when I run it for the second time:

time go build

real    0m0.120s
user    0m0.072s
sys     0m0.088s

This is not only build, but also some of go tools such as fmt. It takes 0.12 seconds on linux, but almost 3 seconds on windows. Other tools like guru, gocode, etc. suffer the same problem, making code development very slow.

I'm using golang 1.11. I'm using an SSD and everything is running locally. Sorry I wish I could be more helpful but I really have no idea where to start to debug this.

Does anyone has an idea what's going on?

Answer 1

It seems that the build cache is disabled on your Windows and enabled on your Linux.

Go build keeps the result of compilations and reuse it if the .go file hasn't changed. That's why your second build is so fast in Linux.

If you disable it, not only your code, but also all the dependancies must be recompiled each time. Thus even if you change your code, all the libs (here "fmt") are already in cache.

To test it, run go clean -cache before the go build on Linux, and see if the time correspond to the time on your Windows. Then if it matches, you have to find why the build cache is disabled on Windows.

You can see the cache directory by typing go env GOCACHE . If the response is off, the cache is off. Otherwise verify that the repository exists and it has the right permissions.

You can choos the cache directory by setting the value of the GOCACHE environment variable (sorry I don't know how to do this in Windows).

Answer 2

I was having same issue. Turns out I had a really big directory with 1000s of large files in the same location where the binary was. Moving the big dir out to a different location resolved the issue. This was in a macOS.