Go 1.5 compile times

<p>While compile times were expected to increase with 1.5, I didn&#39;t expect them to be this bad.</p> <p>Go 1.4.2</p> <ul> <li>real 3.768s</li> <li>user 6.720s</li> <li>sys 1.387s</li> </ul> <p>Go 1.5</p> <ul> <li>real 18.108s</li> <li>user 50.021s</li> <li>sys 4.739s</li> </ul> <p>edit: Running OS X. Cross compiling for windows/amd64 does not exhibit the same extreme slowness and windows/386.</p> <p>running: GOOS=windows GOARCH=386 go install std improved the compile time considerably. This may be an issue with HomeBrew.</p> <p>edit2: finally have my compile times down to normal, go build -i</p> <hr/>**评论：**<br/><br/>TheMerovius: <pre><p>Have you tried go build -v to find which packages in particular are slow?</p></pre>jnewmano: <pre><p>Thank you for the suggestion. My build for windows/386 is rebuilding everything while windows/amd64 does not. That would explain the difference.</p> <p>My native build for darwin interestingly is rebuilding a handful of packages each time.</p></pre>Ainar-G: <pre><p>Try <code>go install std</code> on 386. Maybe your stdlib is stuck with 1.4.2, so 1.5 has to rebuild everything.</p></pre>jnewmano: <pre><p>Awesome -- It&#39;s down to 8s now. </p> <p>It&#39;s now rebuilding all of the non-std packages on each run. Do you have any idea where the tmp files are stored? (I checked $GOPATH/pkg and don&#39;t see a windows_386 folder there)</p></pre>Ainar-G: <pre><p>Don&#39;t remember exactly. I think it&#39;s safe to just delete the whole $GOPATH/pkg and let the compiler rebuild it on the first run.</p> <p>Also, if my advice helped you, it&#39;d be nice to edit the OP post with the instructions, so that other people would solve their issues more quickly.</p></pre>FIuffyRabbit: <pre><p>When upgrading versions it is recommended to delete your $GOPATH/pkg. </p></pre>SpaceDetective: <pre><p>Somebody on go-nuts found that go install has not deteriorated quite as much as go build. In case that helps...</p></pre>QThellimist: <pre><blockquote> <p>Go build just compile the executable file and move it to destination. Go install do a little more. It move the executable file to $GOPATH/bin and cache all non-main packages which imported to $GOPATH/pkg. the cache will be use in the next compile if it not changed yet. </p> </blockquote> <p>It is a normal behaviour</p></pre>jnewmano: <pre><p>I am cross compiling for windows. Building for windows/386 is now extremely slow while windows/amd64 compiles at comparable speeds to 1.4.2. </p> <p>Unfortunately, I am stuck with windows/386.</p></pre>SpaceDetective: <pre><p>OK I don&#39;t know any more myself I&#39;m afraid. But you might find more help on the go-nuts forum...</p></pre>jnewmano: <pre><p>My post on go-nuts is waiting moderation :(</p></pre>SpaceDetective: <pre><p>You can maybe read through the others in the last 2 weeks. I&#39;ve seen relevant discussions.</p></pre>kron4eg: <pre><p>It looks like you cross-recompile stdlib every time you run cross-compilation.</p> <p>In case if you compile for your host platform/arch, you already have .a files of stdlib in GOROOT/pkg, but it&#39;s not the case if you cross-compile</p></pre>jnewmano: <pre><p>I should have mentioned that I am running on OS X. So both windows/386 and windows/amd64 builds are being cross compiled. </p></pre>kron4eg: <pre><p>I&#39;m on macos too, </p> <pre><code>$ export GOOS=windows $ export GOARCH=386 $ time go install dbox/cmd/... real 0m7.356s user 0m20.768s sys 0m3.096s </code></pre> <p>So first time I&#39;ve compiled with <code>GOOS=windows GOARCH=386</code> took quite a long time, but in <code>$GOROOT/pkg</code> now I have <code>windows_386</code> with stdlib compiled for this combination. Consequent cross-compile run much faster (of course I&#39;ve removed <code>$GOPATH/pkg</code> and binary artefact)</p> <pre><code>$ time go install dbox/cmd/... real 0m2.121s user 0m3.935s sys 0m0.545s </code></pre></pre>NihiloSanctumEstne: <pre><p>wow! what a jump!</p></pre>