-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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: increased toolchain binary sizes #70699
Comments
Related Issues
Related Code Changes
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
Those seem fairly large. I preemptively marked this as a release blocker, but maybe OK after RC1. Thoughts? |
CC @golang/compiler |
Is this something about toolchain binaries in particular? I checked a few binaries in our private codebase (all in the 30-60 MB range) and they only get a bit larger between 1.23 and tip (<2%). |
There isn't much more code. |
Looks like dwarf, 1.23.2 binaries have their dwarf stripped, tip binaries do not. I thought we stripped toolchain binaries. Maybe only for release? |
Yeah, we strip toolchain binaries for releases https://cs.opensource.google/go/go/+/master:src/cmd/dist/build.go;l=1393 |
These numbers look much better after using distpack (the proper flags). I will update the numbers and remove the release blocker label. |
Locally I see the following for
The difference in the binary sizes is 1128962 (locally). The extra sections in the gotip copy of gofmt that are not in 1.23.1 copy add up to 1068084 bytes (95%). |
The release binaries look much better in terms of the size increase (built with
|
Thanks @cagedmantis . objdump's increase is somewhat reasonable, as we added more disassembler support (e.g. s390x disassembler). pprof supports disassembling, so it is probably also reasonable. The disassembler symbols (golang.org/x/arch stuff) also show up in nm and addr2line, causing them to increase as well. In theory I don't think they need disassembler symbols, so this is unfortunate. I'll see if we can remove those symbols from nm and addr2line. |
fwiw, I've found that evcc Linux binary slightly shrinks from 1.23 to tip: 91485682 vs 90495826 bytes. |
Change https://go.dev/cl/634916 mentions this issue: |
After nm, addr2line, objdump, and pprof, the next ones are asm and buildid. One part that they depend on now but not in Go 1.23 is crypto FIPS stuff, as they perform various crypto hash operations. In 1.23 most of the hash operations use notsha256, which is deleted in CL 610599 and switched to real sha256, which now depends on FIPS things. We get some binary size back if we revert back to notsha256. Not completely, though. Another place for at least cmd/asm is that they now contain a number of different instantiations of slices.Sort routines. The old code was using sort.Sort or sort.Slice, which is not generic. I guess this increase is okay... |
Currently, cmd/internal/objfile provides dissassembly routines for various architectures, which depend on dissassemblers from x/arch. cmd/internal/objfile is imported in tools that need dissassembly (objdump, pprof) and tools that don't need dissassembly (nm, addr2line). Adding/improving disassembly support for more architectures can cause binary size increase, and for some tools (nm, addr2line) it is not necessary. This CL breaks out dissassembly routines to a different package, which is only imported in tools that need dissassembly. Other tools can depend on cmd/internal/objfile without the disassembly code from x/arch. This reduces binary sizes for those tools. On darwin/arm64, old new cmd/addr2line 4554418 3648882 -20% cmd/addr2line (-ldflags=-w) 3464626 2641650 -24% cmd/nm 4503874 3616722 -20% cmd/nm (-ldflags=-w) 3430594 2609490 -24% For #70699. Change-Id: Ie45d5d5c5500c5f3882e8b3c4e6eb81f0d815292 Reviewed-on: https://go-review.googlesource.com/c/go/+/634916 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
The tool I wrote includes a diff go binary feature that might come in handy. https://github.com/Zxilly/go-size-analyzer?tab=readme-ov-file#diff-mode |
I did another run with
The changes we inspected are all more or less expected (supporting more features, reasonable refactoring, etc.). I don't think we need to do anything more on this at the moment. Thanks. |
Compared to 1.23, binary sizes of most toolchain binaries have increased :
The text was updated successfully, but these errors were encountered: