3 May 2012 06:38
Re: "go build" performance question / feature request
On Wed, May 2, 2012 at 7:39 PM, Phil S. <philipp.schumann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hi gophers,
now "go build" is a really neat tool but it seems like it recompiles
all source files everytime,
This is somewhat overstating the case; for a single package, yes, it compiles all source files whenever it recompiles that package. That's not a problem, because the go compilers are blisteringly fast. It does not recompile imported packages that are up-to-date, however, except when you are using local imports. (one of the many reasons not to use them). If you notice that it's compiling a dependent package each time, you need to "go install" them, as by default "go build" won't try to clobber existing installed libraries.
making a clean temp directory that it
later deletes again, even if only one (and quite often fairly small)
source file was changed.
The temp directory is for build artifacts. The number of files changed is irrelevant to what gets put there. The "go build" command "shadows" any stale package archives by compiling them into this temp directory in favor of blowing away whatever may or may not be installed in $GOPATH/pkg without permission.
Now if I went the manual way with 6g and 6l, I would only have to 6g
the changed file and then 6l the output of that, and 6l whatever
depends on it up to the main package.
That is indeed what the go tool does, when you tell it to do so (via "go install").
Which should be a great deal faster than brute-force recompiling and
relinking a bigger package's entire src tree.
Again, that's not what it does.
I presume go build already does parse imports to build a dependency
tree in order to issue gc and ld calls in the proper order.
Yep, it does. "go list -f {{.Deps}} ." to see :)
RSS Feed