vim-go
vim-go copied to clipboard
fatih
:GoBuild is slower than expected when rebuilding binaries
If I compile a file that has no changes to the file contents or dependencies using :GoBuild, I would expect it to take advantage of the build cache from the last time it compiled. Instead, vim-go issues go build -tags '' . errors from the directory of the file I am attempting to compile. This command never takes advantage of the build cache - it takes 4 seconds for the package I am trying to compile.
By contrast, :GoInstall does take advantage of the build cache. It seems like it is strictly better to use than :GoBuild. Even if you replaced :GoBuild with :GoInstall followed by rm -rf of the created artifacts, it seems like it would be faster than "go build."
vim-go purposefully builds the package of the current file and the errors package so that a build result file won't be produced. From http://golang.org/cmd/go:
When compiling multiple packages or a single non-main package, build compiles the packages but discards the resulting object, serving only as a check that the packages can be built.
:GoInstall's approach isn't a viable solution for vim-go, because it's not known where the file might be installed to or whether it is safe to delete afterwards.
It might be possible to build to /dev/null on *nix and NUL on Windows, though, so that multiple packages don't have to be passed to get go build to not produce a file.
I guess I'm not so much worried about that as I am about it being a fast operation... is there no way to get go build to be fast without producing an artifact?
My understanding was each library builds a .a file and it seems like checking those intermediate results should be fast even if no artifact is actually built...
That's not a decision that's up to vim-go. I agree that it would be optimal. Have you checked to see whether there's an issue for this on github.com/golang/go?
I experimented with using go build -o /dev/null . instead of go build . errors, but there was no performance improvement. Some further experimentation shows that the performance lag you're referring to only happens when building binaries; rebuilding library packages is fast as-is and seems to re-use the cache.
I don't think there's anything we can do to improve the situation, but I'm open to ideas or any data that shows that my assessment is wrong.
Given that there's a Go issue for this now, I'm going to leave this open so that we can track the linked Go issue and improve vim-go if/when the enhancement is made in Go.
when i use GoRun, sometimes vim did not respond and began hang, in this situation, i had to kill vim process and reopen a new vim process, what is the problem.
