Go: all: unstripped binary size growth between Go 1.9 and 1.10

[junland]

Can't seem to comment on issue #6853 , anyways I've ran some test's on binary size with a basic project using net/http and a couple of stdlib packages. Here are my results.

Repo Source

Reported binary sizes for Go version 1.10: 
Size of unstripped binary: 7131073 bytes or 6.9M
Size of stripped binary: 4476192 bytes or 4.3M
Size of compressed stripped binary: 1622540 bytes or 1.6M

Reported binary sizes for Go version 1.9.4: 
Size of unstripped binary: 6583142 bytes or 6.3M
Size of stripped binary: 4486432 bytes or 4.3M
Size of compressed stripped binary: 1601808 bytes or 1.6M

Commands used:

Unstripped: go build -o sled-raw
Stripped: go build -ldflags="-s -w" -o sled-stripped
Compressed: go build -ldflags="-s -w" -o sled-compressed && upx -9 -q ./sled-compressed

Unstripped there is a ~8% difference between 1.10 and 1.9.4 (1.9.x being slimmer than 1.10), however stripped there was a reduction in size in 1.10 but only about .23%. Using UPX (Plus a stripped binary) I saw only 1.28% difference in size for both versions (It's out of scope but thought I would include the number.).

Hope this gives some insight on binary sizes for this new release and future releases.

EDIT: Highlighted percentages.

[mvdan]

Is there a specific problem that you are pointing out here, or is this just about binaries still being too big?

If what you're concerned about is the size of the debug info, perhaps you're after https://github.com/golang/go/issues/11799.

[junland]

Not a specific problem I'm pointing out, just information for #6853, if that issue was opened I would've just commented there.

This issue can be closed out thou.

[mvdan]

I believe that these old and generic issues tend to be moderated heavily because otherwise they get long really fast.

Could you clarify what is the information you're trying to provide? Are the numbers that you posted above unexpected?

[junland]

Gotcha.

Just the binary size difference from 1.9.4 to 1.10, obviously the sizes are still growing. Think that this is excepted but just wanted to give helpful information (hopefully) to anyone working on this issue of #6853.

Sorry about the issue spam. :/

[mvdan]

I see, thanks. Let's leave this issue open for now, in case I'm wrong about it being a duplicate of debug info compression.

[ghost]

A bit dated perhaps, but for GNU/Linux 386 here are some command lines used for stripping a bootstrapped go1.9.2 and tools subrepo.

On Windows x86 for both Go source compiles and the subrepo substitute PE for ELF in the latter's lines.

[adamdecaf]

I'm pretty sure stripping binaries isn't supported as it creates a lot of instability.

See: https://blog.filippo.io/shrink-your-go-binaries-with-this-one-weird-trick/

[dgryski]

Stripping binaries should be safe. Any issues with stripped binaries is a bug. https://groups.google.com/forum/#!topic/golang-dev/ABppMOjYP6w

[ghost]

from Go Forum

https://forum.golangbridge.org/t/stripping-binaries/6708

[FiloSottile]

@junland Thanks, I reported your data on the main issue.

(Stripping is still a little controversial, but I think the consensus is that strip(1) is safe now, even if it's not tested. Dominik has a good detailed blog post: https://dominik.honnef.co/posts/2016/10/go-and-strip/. I removed that mention from mine.)

[junland]

Awesome thanks @FiloSottile

Just a side note I forgot to mention, these binaries were built on Ubuntu 17.04 LTS with the x86-64 platform.

[dbaroncelli]

With go 1.11 binaries got even bigger.
In my case it went from 22MB to 29MB.

[ALTree]

@dbaroncelli If you compile stripped binaries (-ldflags="-w -s" on compilation), the size difference with 1.10 should go away. Does it?

[dbaroncelli]

@ALTree thanks for the reply
Is there a good reason why the binaries keep those extra information?
It would make more sense to me, that such information is removed by default, and there would be flags to include them, rather than to exclude them.

[ALTree]

@dbaroncelli

It would make more sense to me, that such information is removed by default, and there would be flags to include them, rather than to exclude them.

That's debatable. Anyway there's a proposal by Rob to not include debug info by default: #26074. It'll likely be discussed and decided upon in the next development cycle.

[dbaroncelli]

Thanks @ALTree
I am glad Rob Pike is also concerned about the growing size of the binaries.
I am confident that Go 1.12 will produce stripped binaries by default.