
Golang SSA performance numbers - signa11
https://groups.google.com/forum/#!topic/golang-dev/m1r8kSle30Y
======
andrewstuart2
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

~~~
wtbob
> 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.

~~~
jerf
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.

~~~
vessenes
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.

------
andrewflnr
Can anyone say why the Mandelbrot benchmark, out of all of them, was slower
with SSA? Any chance it was just a fluke?

~~~
davecheney
The inner loop went from 15 instructions to 16 because the register optimiser
is not finished yet.

~~~
rurban
Thanks. That's what I asked on the list, but HN was faster :)

------
vessenes
I just posted some results there on our own codebase.

Server load time dropped from 25.5s or so to 22.2s; a really nice win on a
large and varied codebase for these improvements. I can't imagine not wanting
them.

