Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Unless I missed it, it is surprising the lack of benchmarks or mentioning how compile speed compares with the previous iteration.

I'm not saying it would be necessary slower than a compiler written in C, if they wrote the more critical parts in assembler, but you would think compiling speed would be one of the outstanding discussion points, after a major rewrite.



There were a few slides with numbers and detailed performance graphs in Andrew's preceding talk. See http://talks.golang.org/2015/state-of-go-may.slide#10 and nearby slides.


If I'm not mistaken, these graphs refer to the speed of the code generated with the compiler, not of the compiler itself.


This slide mentions that initial go-version dropped down to 1/10th of the C in performance:

http://talks.golang.org/2015/gogo.slide#15

While the next mentions that the got it back up -- but not by how much.

It wasn't exactly crystal clear from the docs/website, but apparently[1] "master" is go1.5 -- so with go1.4 on windows, one can:

    # from a git bash, already have go1.4 installed
    git clone https://github.com/golang/go.git go.git
    cd go.git/src
    git checkout master
    export GOROOT_BOOTSTRAP=$GOROOT
    time cmd "/c all.bat"

    real    0m29.078s
    user    0m0.015s
    sys     0m0.030s

    # with our fresh go1.5 (see more below):
   
    real    0m33.034s
    user    0m0.000s
    sys     0m0.000s
So, apparently doing the same job (compiling go1.5 "master") with go1.5 and go1.5 -- there's a small hit (I ran a couple of runs with each, the numbers are consistent to ~1sec, so call it 29 for 1.4 and 33 for 1.5).

Note that if you want to do this, in particular the second part, it gets a bit hairy, as "go.exe" needs to be in your path, and you need to change your gopath (easy).

On my system, I had everything in $HOME/opt (%HOME%\opt), so all i did was move opt\go to opt\go1.4, and copy go.git to \opt\go. One can confirm the right version is being run with 'go version' (and 'cmd "/c go version"' from bash).

[1] After a few useless hits, I found: https://godoc.org/golang.org/x/mobile/cmd/gomobile -- which mentions what's needed to actually test go 1.5. If they want testers, they should probably add something under "install from source" on golang.org about "And if you want to live on the edge, or say, test go in go, use "master")


(I'd be more confident in this test if someone could point me at a past commit where go1.5 works, builds with go1.4 and itself, but is (much 10x) slower...).


Distinctions like that makes googling for speed of the compiler itself annoying.. :-)


There was some discussion about it on golang-dev:

https://groups.google.com/forum/#!msg/golang-dev/6obxRcm-rqc...


Does the speed it takes to compile the compiler really matter?

Edit: Of course, faster speeds would be interesting to hear about, so great question.


"We believe it's worth trying again with a new language, a concurrent, garbage-collected language with fast compilation."

Fast compilation is an explicit goal of Go, so they certainly think it matters.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: