Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
junland opened this issue Feb 19, 2018 · 16 comments
Closed

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

junland opened this issue Feb 19, 2018 · 16 comments

Comments

@junland
Copy link

junland commented Feb 19, 2018

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
Copy link
Member

mvdan commented Feb 19, 2018

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 #11799.

@junland
Copy link
Author

junland commented Feb 19, 2018

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
Copy link
Member

mvdan commented Feb 19, 2018

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
Copy link
Author

junland commented Feb 19, 2018

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
Copy link
Member

mvdan commented Feb 19, 2018

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.

@mvdan mvdan changed the title all: binary size improvements all: unstripped binary size growth between Go 1.9 and 1.10 Feb 19, 2018
@ghost
Copy link

ghost commented Feb 19, 2018

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
Copy link
Contributor

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
Copy link
Contributor

dgryski commented Feb 20, 2018

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

@ghost
Copy link

ghost commented Feb 20, 2018

@FiloSottile
Copy link
Contributor

@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
Copy link
Author

junland commented Feb 21, 2018

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
Copy link

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

@ALTree
Copy link
Member

ALTree commented Aug 25, 2018

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

@dbaroncelli
Copy link

@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
Copy link
Member

ALTree commented Aug 25, 2018

@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
Copy link

dbaroncelli commented Aug 25, 2018

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.

@golang golang locked and limited conversation to collaborators Aug 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants