5 ms·

The last thing I'm curious about is compilation time, especially since that's taken a hit or two recently. I know it's easily a net win with numbers like that,

The last thing I'm curious about is compilation time, especially since that's taken a hit or two recently. I know it's easily a net win with numbers like that, but one of my favorite parts of Go is the quick build times, and thus quick iteration times. Also, since Go is self-compiled, does that mean we'll have to wait until 1.7.1 for the speed improvements to hit the compiler? :-P

Spiritus 11y ago
I've seen the numbers ~10% slower floating around.
- UniQP 11y ago
  [citation needed]
  - matt4077 11y ago
    It's in the mail?! "Tip compiler (with SSA internal checks off) is about 7% slower than go1.6 to compile net/http (go test -a -c -gcflags=-d=ssa/check/off net/http)"
  - Spiritus 11y ago
    There's a couple of mentions of it on r/golang[1], though I don't know the validity behind the claims. [1] https://www.reddit.com/r/golang/comments/48ivj0/devssa_branch_has_been_merged_into_tip/ https://www.reddit.com/r/golang/comments/48ivj0/devssa_branc...
  - nulltype 11y ago
    Well the actual article says 7% slower when compiling the http package.
UniQP 11y ago
I'm sure, you can also self-compile the tip. Would be really interesting if this was done for benchmarks.
bpineau 11y ago
The linked post gives an estimation : > "Tip compiler (with SSA internal checks off) is about 7% slower than go1.6 to compile net/http (go test -a -c -gcflags=-d=ssa/check/off net/http)" ... though we may wonder wether the mesured compiler itself was compiled with or without SSA (with 7% being in the ballpark of the expected SSA gains).
- davecheney 11y ago
  The compiler always compiles itself as part of the bootstrap process. The final compiler is built with itself and thus uses its own SSA code generation.
pjmlp 11y ago
No worries, it will never reach the C and C++ build times which are often measured in minutes and hours.
- UniQP 11y ago
  Compile time is an issue of C++ but not of C.
  - iainmerrick 11y ago
    Yep. A while ago I found myself needing to recompile the Linux kernel for Android, and I was amazed at how fast the build was (I think I last built a kernel in the 90s). It took a lot less time than it takes Android to start up!
  - pjmlp 11y ago
    I used to work in a project around 2000 that would take 1h build time per architecture/OS combination. Doing a full build across HP-UX, Aix, Solaris, Red-Hat Linux and Windows for 32 and 64 bits took almost a full day. EDIT: It was a mix of C and TCL
davecheney 11y ago
> Also, since Go is self-compiled, does that mean we'll have to wait until 1.7.1 for the speed improvements to hit the compiler? :-P No. The compiler compiles itself during the bootstrap phase.
- thethimble 11y ago
  Does the old compiler compile the new compiler after which the new compiler can compile itself? Bootstrapping is incredible.
  - davecheney 11y ago
    Yes.
wtbob 11y ago
> one of my favorite parts of Go is the quick build times One of my favourite parts of Go was the quick build times. It used to feel like 'go build' was as fast as 'python'; sadly, that's no longer the case.
- dilap 11y ago
  Yeah, it got about twice as slow going 1.4 => 1.5, which makes it just slow enough to be annoying. (It's still much faster than something like C++ though, and feels about the same to me as the (snappy) Objective-C.)
  - vessenes 11y ago
    On the flip side, large programs have gone from multi-second GC pauses to unnoticeable. :) I too miss those fast compile times, though.
- jerf 11y ago
  Despite the attractive nuisance of "go build", if you're in a fast save-compile-test cycle, you really want "go install". Both do pretty much the same thing (ignoring where the result goes), but install keeps the intermediate package compilations around and does the minimum, whereas build seems to discard them. Put "-v" on both of them and you can see the differences.
  - jstarks 11y ago
    I think go build -i does the same without putting the result in the bin dir.
  - vessenes 11y ago
    I think this is only true if you're building outside your GOPATH. In my case, build -v, build -v -i, and install all have very similar compile times and only show an edited file being compiled when executed from inside my GOPATH. Each of those averaged 3.5s in my codebase, for example, on a freshly changed file. go install's second run is 250ms, but I assume that's because it knows the file hasn't changed. go build -a shows roughly 60 packages and takes 16s, so I would notice if build or install were accidentally recompiling all of them.

Spiritus 11y ago

I've seen the numbers ~10% slower floating around.

UniQP 11y ago
[citation needed]
- matt4077 11y ago
  It's in the mail?! "Tip compiler (with SSA internal checks off) is about 7% slower than go1.6 to compile net/http (go test -a -c -gcflags=-d=ssa/check/off net/http)"
- Spiritus 11y ago
  There's a couple of mentions of it on r/golang[1], though I don't know the validity behind the claims. [1] https://www.reddit.com/r/golang/comments/48ivj0/devssa_branch_has_been_merged_into_tip/ https://www.reddit.com/r/golang/comments/48ivj0/devssa_branc...
- nulltype 11y ago
  Well the actual article says 7% slower when compiling the http package.

UniQP 11y ago

I'm sure, you can also self-compile the tip. Would be really interesting if this was done for benchmarks.

bpineau 11y ago

The linked post gives an estimation : > "Tip compiler (with SSA internal checks off) is about 7% slower than go1.6 to compile net/http (go test -a -c -gcflags=-d=ssa/check/off net/http)" ... though we may wonder wether the mesured compiler itself was compiled with or without SSA (with 7% being in the ballpark of the expected SSA gains).

davecheney 11y ago
The compiler always compiles itself as part of the bootstrap process. The final compiler is built with itself and thus uses its own SSA code generation.

pjmlp 11y ago

No worries, it will never reach the C and C++ build times which are often measured in minutes and hours.

UniQP 11y ago
Compile time is an issue of C++ but not of C.
- iainmerrick 11y ago
  Yep. A while ago I found myself needing to recompile the Linux kernel for Android, and I was amazed at how fast the build was (I think I last built a kernel in the 90s). It took a lot less time than it takes Android to start up!
- pjmlp 11y ago
  I used to work in a project around 2000 that would take 1h build time per architecture/OS combination. Doing a full build across HP-UX, Aix, Solaris, Red-Hat Linux and Windows for 32 and 64 bits took almost a full day. EDIT: It was a mix of C and TCL

davecheney 11y ago

> Also, since Go is self-compiled, does that mean we'll have to wait until 1.7.1 for the speed improvements to hit the compiler? :-P No. The compiler compiles itself during the bootstrap phase.

thethimble 11y ago
Does the old compiler compile the new compiler after which the new compiler can compile itself? Bootstrapping is incredible.
- davecheney 11y ago
  Yes.

wtbob 11y ago

> one of my favorite parts of Go is the quick build times One of my favourite parts of Go was the quick build times. It used to feel like 'go build' was as fast as 'python'; sadly, that's no longer the case.

dilap 11y ago
Yeah, it got about twice as slow going 1.4 => 1.5, which makes it just slow enough to be annoying. (It's still much faster than something like C++ though, and feels about the same to me as the (snappy) Objective-C.)
- vessenes 11y ago
  On the flip side, large programs have gone from multi-second GC pauses to unnoticeable. :) I too miss those fast compile times, though.
jerf 11y ago
Despite the attractive nuisance of "go build", if you're in a fast save-compile-test cycle, you really want "go install". Both do pretty much the same thing (ignoring where the result goes), but install keeps the intermediate package compilations around and does the minimum, whereas build seems to discard them. Put "-v" on both of them and you can see the differences.
- jstarks 11y ago
  I think go build -i does the same without putting the result in the bin dir.
- vessenes 11y ago
  I think this is only true if you're building outside your GOPATH. In my case, build -v, build -v -i, and install all have very similar compile times and only show an edited file being compiled when executed from inside my GOPATH. Each of those averaged 3.5s in my codebase, for example, on a freshly changed file. go install's second run is 250ms, but I assume that's because it knows the file hasn't changed. go build -a shows roughly 60 packages and takes 16s, so I would notice if build or install were accidentally recompiling all of them.