Compile Go programs 7x faster | Hacker News Reader

Compile Go programs 7x faster

github.com

135 pointssquanching28 comments

This is basically a wrapper for 'go install'. See this post / linked blog posts for an explanation why this is faster/useful: https://twitter.com/davecheney/status/697171533215576064

After reading this discussion and the source of the project, I've flagged this. This "compile Go faster" project really is just about 5 lines of modestly useful bash, and even as someone who often complains people tend to overstate the uselessness of benchmarks, those benchmarks are truly useless. Along with being too small to measure anything useful, almost certainly being dominated by startup overhead, you can't benchmark two fundamentally different things like that. Incremental builds, regardless of language, are not "3x faster" or "9x faster", they're doing fundamentally less work. It's not quite correct to say they're in a different O() class, but that's at least the right sort of thought. O(n^2) algorithms aren't any number of "x" times faster than a O(n^3) algorithm, they're more fundamentally faster than that metric can capture; similarly here.

To the author, I'm not complaining that you have this on github per se, but you may want to make it more clear what's going on here if you're going to submit it to HN. For instance, this is one of those projects where you could literally inline the source into the README.md. And I'd drop the benchmarks, those really aren't useful. Or at least drop the "x times faster" column.

You flagged _the story_, on HN? Don't do that. It's valuable if only as a hook for comments like yours.

The "it could create good comments" is not a good metric for not flagging something, because there is no link for which that is not true, or at least someone would argue for it.

While I again want to emphasize I'm not really being that critical of the author for creating it, because people are welcome to put whatever they want on github, it's a thin piece of content whose thin content is also somewhat misleading, that was upvoted to the top of HN. I'm still comfortable with this, barring the admin staff disagreeing with me.

That's true for off-topic stories, which stories are the actual purpose of the flag button. It's not true for stories we simply disagree with. In this case, you happen to be right, but everyone has a bunch of topics they believe themselves to be right about.

The length of code of a program should not be a metric for how useful or valid it is.

This is a great shortcut for something that I've been doing manually for years and I'm happy to have stumbled on it and the surrounding discussion. Please don't flag stories like this.

I have to echo everything said by @jerf. One additional suggestion is to write a blog post highlighting ways to improve the workflow for go developers and help them to understand why certain things are better than others, as your work here slots in nicely.

You could also explain in detail what goes on behind the scenes in an incremental build.

Yes, never use go build, always use go install!

go build builds everything, whereas go install does an incremental build on the stuff that has changed and installs it (either in GOPATH/bin or GOPATH/pkg).

FYI, there is also `go build -i`, which is behaves like `go build` in terms of what executable artefacts it produces and where it puts them (i.e. it doesn't install stuff in $GOPATH/bin) but preserves object files for all the dependent packages like `go install` does

Why does "go build" build more than what is necessary for "go install"?

Shouldn't "go build" just do incremental builds and be faster across the board?

Running `go build` is a lot like running `make clean` before you compile.

Just use `go build -i` to install everything and compile only packages that have changed.

"all the go commands operate on packages, the use of files is a degenerate case only to support go run"

guilty. typing in "go run" for quick scripts is one hard to conquer habit ;)

For quick scripts I don't see how it's wrong. I mean, even wrong is really just "wasting time a bit" here.

Did not think compiling Go programs was that much of an issue. Many texts reference the fact that the whole standard library can be compiled in sub 10sec.

Since they've switched to a Go compiler from the previous C one, compile times have been pretty terrible.

What was the delta, though? Generally graphs comparing version to version seem pretty okay.

They are still quite good comparing with C and C++ code bases, usually measured in hours for a "make world".

Apparently there are some optimizations coming up on newer versions.

It is not. It was one of the design goals of the language to compile fast...

https://talks.golang.org/2012/splash.article

So I am wondering too what this is all about.

Maybe I'm daft, but his table says 502 lines in 1.558 seconds. So 322 lines/second. I thought the Go compiler was supposed to be amazingly fast? That is not fast at all.

This number is not true I guess. scalac with idomatic Scala code (no Macro's) is at 500-700 loc/sec. (And scalac is considered slow by many people)

Source: https://www.youtube.com/watch?v=WxyyJyB_Ssc

That would be a slowdown of like 4x to current javac, I guess his computer is just not good enough?

I've got a fairly decent machine, 4 years old but it's a 2.3GHz i7 and I've got an SSD. I got about a 1.5s runtime for "go build" on manul too.

Edit - this blogpost has a 18k lines/s though, I wonder what the differences are?

http://ptspts.blogspot.co.uk/2009/11/how-fast-does-8g-in-goo...

Does `go build` use multiple core's?

There's a flag for it, which didn't make a difference (edit - with the new 1.7 compiler it does, but it goes from half that speed to the same figure). Even with a perfect scaling, I'd be about 10x behind a post from 7 years ago.

Perhaps it's compiling a lot more lines than I think? Lots of bits of the standard library I should be including in the line count?

actually I guess stdlib is compiled, too. But golang before 1.5 was faster to compile. I just wonder how much difference it would make with multicore's. I mean scala beats down my new Xeon E5-2670 workstation on all threads.

Just use `go install`.

I rarely use `go build`. `go install` always faster.

`goinstall` predates the entire `go` tool.

Looks like something like this should be embedded in a Go IDE.

I'd love to see 5-7x faster Clojure{Script} builds :)

Reply on news.ycombinator.com