Show HN: Shed Light on Your Go Binary Bloat with Go Size Analyzer(github.com)
github.com
Show HN: Shed Light on Your Go Binary Bloat with Go Size Analyzer
https://github.com/Zxilly/go-size-analyzer
6 コメント
This is great — I dragged a binary to the demo URL and it made me realize I had forgotten to pass `-ldflags="-s -w"` to strip the DWARF and symbol tables when I was building the binary. This will take my binaries from 25 MB down to 18 MB, a ~30% reduction in space. The container I'm building drops from 45 MB down to 36 MB, a 20% reduction. Every little bit helps when it comes to deploy times and space/speed savings!
(for the container image size analysis I used dive, available here https://github.com/wagoodman/dive)
(for the container image size analysis I used dive, available here https://github.com/wagoodman/dive)
First, great tool! The README makes me want to try it immediately.
I love how the Kubernetes client for Go is always the culprit for adding dozens of megabytes to binary sizes. Thankfully, its impact on binary size is decreasing as the codebase adopts generics.
Out of curiosity, how well does this work with stripped binaries? Many people interested in reducing binary size will often strip debug symbols and add "-a -s" to LDFLAGS, so what identifying information of a package is left in a binary? Besides VCS information (unless the binary was also built with -buildvcs=false so Git commit hashes aren't baked into the binary).
I love how the Kubernetes client for Go is always the culprit for adding dozens of megabytes to binary sizes. Thankfully, its impact on binary size is decreasing as the codebase adopts generics.
Out of curiosity, how well does this work with stripped binaries? Many people interested in reducing binary size will often strip debug symbols and add "-a -s" to LDFLAGS, so what identifying information of a package is left in a binary? Besides VCS information (unless the binary was also built with -buildvcs=false so Git commit hashes aren't baked into the binary).
heads up that you probably want `-ldflags="-w -s"`, not `"-a -s"`, since `-a` is now a no-op. See `go tool link` for more info.
Even if the debugging information is stripped out, this tool can still extract a lot of information. This is because Go keeps a lot of specific information about functions in its pclntab table inside the binary for reflection, GC or other work. The tool is able to analyse this part of the information.
Also, it includes a rudimentary decompiler for extracting possible static data calls from the binary, which is simple, but seems to work well.
Thanks! This looks really nice and handy. I wish it could work with any native binary but I understand that it focuses on Go specifically.
On Windows, there's SizeBench[0] but it doesn't work on macOS and non-PE files, and I miss having a tool like that.
[0]: https://github.com/microsoft/SizeBench, likely used to be an internal tool that was open-sourced
On Windows, there's SizeBench[0] but it doesn't work on macOS and non-PE files, and I miss having a tool like that.
[0]: https://github.com/microsoft/SizeBench, likely used to be an internal tool that was open-sourced
Try this: https://www.jackyoustra.com/binary
Bloaty seems to be what I was looking for. It's limited, requires symbols for some options and doesn't have GUI but is a start. Probably someone already made GUI for it and I just need to search.
Thank you both.
I noticed that https://www.jackyoustra.com/binary appears to fail with 'Reference Error: Can't find variable: SharedArrayBuffer' on Safari when you give it a binary.
On Firefox, it does not display the size of sections unless you hover the cursor. Not sure if it's intended - just noting here.
Thank you both.
I noticed that https://www.jackyoustra.com/binary appears to fail with 'Reference Error: Can't find variable: SharedArrayBuffer' on Safari when you give it a binary.
On Firefox, it does not display the size of sections unless you hover the cursor. Not sure if it's intended - just noting here.
Only tested with chrome! I'll add some cross browser tests and get back to you soon, thanks!
That is intended behavior, but looking back seems kind of silly? I'll fix!
That is intended behavior, but looking back seems kind of silly? I'll fix!
You may want to try google/bloaty.
[deleted]
I have been using this for a while to reduce the size of boxcars[0]. While the web UI is awesome, I recommend the TUI mode instead (gsa --tui <binary>), as I find it much easier to use and understand.
0. https://code.rocket9labs.com/tslocum/boxcars
0. https://code.rocket9labs.com/tslocum/boxcars
Nice! I have something similar that works for other binary types too, try it out! https://www.jackyoustra.com/binary
That's awesome! But when i switch between the twiggy and bloaty, the ui freeze for a while, maybe WebWorker can resolve this problem.
Ah yeah just kinda slapped this together! I'll maybe spend a little bit of time optimizing it.
Which dependencies are eating up your binary size
Unexpected bloat from standard library or vendor packages
Size changes between binary versions with a visual diff
Key features that set it apart:
Interactive treemap visualizations (check out the demo: https://gsa.zxilly.dev)
Slick terminal UI for deep diving into package hierarchies
Cross-platform support (works on Linux, macOS, and Windows binaries)
Export to SVG for easy sharing and documentation or just visualize the CI process
Whether you're optimizing for edge devices, reducing Docker image sizes, or just curious about what's really inside your Go binaries, this tool provides detailed insights. .