Open robpike opened 10 years ago
Just for added reference, this are the size on go 1.1.2 vs 1.2 with OS X 10.9 and Xcode 5 (darwin gcc llvm 5.0 x86_64): $ ls -l *1.* -rwxr-xr-x 1 j staff 1525984 2 Dez 21:44 hello_1.1.2 -rwxr-xr-x 1 j staff 2192672 2 Dez 21:40 hello_1.2 $ size *1.* __TEXT __DATA __OBJC others dec hex 1064960 94720 0 76000 1235680 12dae0 hello_1.1.2 1433600 147896 0 177440 1758936 1ad6d8 hello_1.2
This issue was updated by revision f238049a0073538caecfad1c60238a271426f43.
R=golang-dev, rsc CC=golang-dev https://golang.org/cl/35940047
In this context, please reevaluate if the golang binaries can be changed to work with UPX (ultimate packer for executables).¹² For a small amount of computing power, upx can reduce the size of a binary down to a quarter of its original size. You can authenticate this using a existing example ›fixer‹ programm for golang binaries on linux/amd64.³ While this approach doesn't fix the root of the problem – only the symptoms – it would be nice to have this possibility always on hand. For technical background of this problem (PT_LOAD[0].p_offset==0), please look at the UPX bugtracker⁴. ¹ http://upx.sourceforge.net/ ² https://en.wikipedia.org/wiki/UPX ³ https://github.com/pwaller/goupx ⁴ http://sourceforge.net/p/upx/bugs/195/
re #10, my #9 reply is to #8, which is about an entirely different problem. i'm not saying that the ever-growing binaries is not our problem, only that i don't believe that upx not accepting our binaries is our problem. it's clear that upx isn't able to handle all possible and correct ELF files (i.e. if the kernel can execute our binaries just fine, it's upx's problem to not be able to compress them).
More detail. The Plan 9 symbol table is about to be deleted. Here is a reference point, adding one new entry to the list above: $ ls -l *1.* -rwxr-xr-x 1 j staff 1525984 2 Dez 21:44 hello_1.1.2 -rwxr-xr-x 1 j staff 2192672 2 Dez 21:40 hello_1.2 -rwxr-xr-x 1 j staff 2474512 Feb 18 20:27 hello_1.2.x $ size *1.* __TEXT __DATA __OBJC others dec hex 1064960 94720 0 76000 1235680 12dae0 hello_1.1.2 1433600 147896 0 177440 1758936 1ad6d8 hello_1.2 1699840 160984 0 188944 2049768 1f46e8 hello_1.2.x Text has grown substantially, as has data. At least some of this is due to new annotations for the garbage collector.
More detail. The Plan 9 symbol table is about to be deleted. Here is a reference point, adding one new entry to the list above: $ ls -l *1.* -rwxr-xr-x 1 r staff 1191952 Nov 30 10:25 x.1.0 -rwxr-xr-x 1 r staff 1525936 Nov 30 10:20 x.1.1 -rwxr-xr-x 1 r staff 2188576 Nov 30 10:18 x.1.2 -rwxr-xr-x 1 r staff 2474512 Feb 18 20:27 hello_1.2.x $ size *1.* __TEXT __DATA __OBJC others dec hex 880640 33682096 0 4112 34566848 20f72c0 x.1.0 1064960 94656 0 75952 1235568 12da70 x.1.1 1429504 147896 0 177440 1754840 1ac6d8 x.1.2 1699840 160984 0 188944 2049768 1f46e8 hello_1.2.x Text has grown substantially, as has data. At least some of this is due to new annotations for the garbage collector.
More detail. The Plan 9 symbol table is about to be deleted. Here is a reference point, adding one new entry to the list above: $ ls -l *1.* -rwxr-xr-x 1 r staff 1191952 Nov 30 10:25 x.1.0 -rwxr-xr-x 1 r staff 1525936 Nov 30 10:20 x.1.1 -rwxr-xr-x 1 r staff 2188576 Nov 30 10:18 x.1.2 -rwxr-xr-x 1 r staff 2474512 Feb 18 20:27 hello_1.2.x $ size *1.* __TEXT __DATA __OBJC others dec hex 880640 33682096 0 4112 34566848 20f72c0 x.1.0 1064960 94656 0 75952 1235568 12da70 x.1.1 1429504 147896 0 177440 1754840 1ac6d8 x.1.2 1699840 160984 0 188944 2049768 1f46e8 x.1.2.x Text has grown substantially, as has data. At least some of this is due to new annotations for the garbage collector.
This issue was updated by revision 964f6d3ec4c6e2bed377878bd2862767bfae463.
Nothing reads the Plan 9 symbol table anymore. The last holdout was 'go tool nm', but since being rewritten in Go it uses the standard symbol table for the binary format (ELF, Mach-O, PE) instead. Removing the Plan 9 symbol table saves ~15% disk space on most binaries. Two supporting changes included in this CL: debug/gosym: use Go 1.2 pclntab to synthesize func-only symbol table when there is no Plan 9 symbol table debug/elf, debug/macho, debug/pe: ignore final EOF from ReadAt LGTM=r R=r, bradfitz CC=golang-codereviews https://golang.org/cl/65740045
For my test case before/after deleting the Plan 9 symbol table: % ls -l ... -rwxr-xr-x 1 r staff 2474512 Feb 18 20:27 hello_1.2.x -rwxr-xr-x 1 r staff 2150928 Feb 18 22:28 hello_1.2.y % size ... __TEXT __DATA __OBJC others dec hex 1699840 160984 0 188944 2049768 1f46e8 hello_1.2.x 1376256 160984 0 188944 1726184 1a56e8 hello_1.2.x % So deleting the Plan 9 symbol table pretty close to exactly compensates for the GC information. We're back at Go 1.2 levels, still far too large but it's a start.
This issue was updated by revision 2541cc81978dc5e41e2e2db6345d8ca7a365ca8.
Every function now has a gcargs and gclocals symbol holding associated garbage collection information. Put them all in the same meta-symbol as the go.func data and then drop individual entries from symbol table. Removing gcargs and gclocals reduces the size of a typical binary by 10%. LGTM=r R=r CC=golang-codereviews https://golang.org/cl/65870044
This issue was updated by revision ae38b03f6cab6a25f9d8d34a39e33db9857dce2.
For an ephemeral binary - one created, run, and then deleted - there is no need to write dwarf debug information, since the binary will not be used with gdb. In this case, instruct the linker not to spend time and disk space generating the debug information by passing the -w flag to the linker. Omitting dwarf information reduces the size of most binaries by 25%. We may be more aggressive about this in the future. LGTM=bradfitz, r R=r, bradfitz CC=golang-codereviews https://golang.org/cl/65890043
After removing gcargs from the symbol table (stepping across CL 65870044) % ls -l x.1.2.[yz] -rwxr-xr-x 1 r staff 2150928 Feb 18 22:28 hello_1.2.y -rwxr-xr-x 1 r staff 1932880 Feb 19 08:14 hello_1.2.z % size x.1.2.[yz] __TEXT __DATA __OBJC others dec hex 1376256 160984 0 188944 1726184 1a56e8 hello_1.2.y 1376256 160984 0 110160 1647400 192328 hello_1.2.z % It's now smaller than at 1.2 but still much bigger than 1.1, let alone 1.0.
Let's not use this issue as a discussion list. Please ask questions on golang-dev. Thanks. pprof not working is issue #7452.
Labels changed: added restrict-addissuecomment-commit.
This is as fixed as it is going to be for Go 1.3. Right now at tip + CL 80370045 on darwin/amd64, compiling this program: package main import "fmt" func main() { fmt.Println("hello, world") } I get 1830352 bytes for the binary. Assuming this is the same case for which Rob's numbers are reported, by this metric Go 1.3 will roll back more than half the size increase caused by Go 1.2 (relative to Go 1.1). Will leave further improvement for Go 1.4.
Labels changed: added release-go1.4, removed release-go1.3.
This issue was updated by revision a26c01ad446d2853f0c6a7ddaacadb02efa00b7.
LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/80370045
From Go 1.4 to Go tip on darwin/amd64, helloworld grows from 1927792 to 2344944 bytes (+22%).
Camlistore shows more modest increases, but they are non-trivial nevertheless:
File | Go 1.4 | Go tip | Delta |
---|---|---|---|
camdeploy | 12750156 | 13512052 | +5.97% |
camget | 12378300 | 13261956 | +7.13% |
camlistored | 28374844 | 29469892 | +3.85% |
cammount | 13586156 | 14496036 | +6.69% |
camput | 14040524 | 14954180 | +6.50% |
camtool | 23245596 | 24260084 | +4.36% |
devcam | 19250156 | 20153892 | +4.69% |
hello | 12925420 | 13816564 | +6.89% |
publisher | 19047228 | 19964308 | +4.81% |
One more data point. A program containing just a single non-linker-strippable string of length 500000 grows from 1.12mb in Go 1.4 to 1.56mb at tip (+39%). I tried bisecting and found (unfortunately) that the growth was pretty slow and steady: I saw file sizes along the way including at least 1.15, 1.25, 1.30, 1.34, and 1.47, and I wasn't looking hard.
package main
var s = "....very long...."
func main() { _ = s[0] }
Marked this as 1.6. I don't expect it to be fixed but I want to see us develop an understanding of what's going on.
CL https://golang.org/cl/17398 mentions this issue.
CL https://golang.org/cl/16610 mentions this issue.
CL https://golang.org/cl/19692 mentions this issue.
CL https://golang.org/cl/19697 mentions this issue.
CL https://golang.org/cl/19695 mentions this issue.
CL https://golang.org/cl/19694 mentions this issue.
CL https://golang.org/cl/19696 mentions this issue.
CL https://golang.org/cl/19698 mentions this issue.
CL https://golang.org/cl/19768 mentions this issue.
CL https://golang.org/cl/19770 mentions this issue.
CL https://golang.org/cl/19766 mentions this issue.
CL https://golang.org/cl/19769 mentions this issue.
CL https://golang.org/cl/19767 mentions this issue.
CL https://golang.org/cl/19790 mentions this issue.
CL https://golang.org/cl/19813 mentions this issue.
CL https://golang.org/cl/19852 mentions this issue.
CL https://golang.org/cl/19916 mentions this issue.
CL https://golang.org/cl/19987 mentions this issue.