Reducing the size of Go binaries by up to 77%

33 points by hemitheconyx

reezer

First post and self-authored Datadog advertising article. When you click on "I am the author" it links to two sentences that essentially tell you not to do this.

wrs

The article was technically interesting, and I'd say finding out that the Datadog agent was over a gigabyte is, if anything, anti-advertising!
mariusor

Yeah, but it's still a decent article, isn't it?
adriano

It was a worthy read. I'll turn a blind eye.

simonw

This article showed me https://gsa.zxilly.dev/ which is really nice, you can drop a Go binary on there and see what's in it as a treemap, all running in the browser with WebAssembly.

symgryph

I'm surprised they didn't mention the other optimizations such as minus s minus w and the typical other ones. You can do that. Really reduce the size without having to do all this. Not that it wasn't interesting.

klingtnet

... other optimizations such as minus s minus w ...

What is "minus s minus w"?
- symgryph
  
  Ldflags you can pass on build
- ptman
  go help build go tool link -help go build -trimpath -ldflags "-s -w"
mariusor
I'm not sure what "compressed size" means. Is it the the container repository compression, or something like UPX binary compression?

I'm using the later and there's about 30-40% binary size decrease for its usage, but the time it takes to compress is horrendous. For something that builds a lot of images it's quite disproportionate with the times of the rest of the image build pipeline.
```
upx -q --mono --no-progress --best bin/fedbox
  24408226 ->   9636292   39.48%   linux/amd64   fedbox
```
Another thing which I decided to do in order to decrease the sizes is to collapse binaries.

My web applications tended to have a control CLI tool that communicated with the main server binary for various operations. However that meant that the size of the image was twice what it is now that I moved the control commands inside the same binary with the server... Probably not something that everyone needs to think about, but it's definitely the cheapest method for halving your image sizes.
- kornel
  
  They probably mean .deb files, which use xz compression (or gzip if your tooling is trying hard).
  - mariusor
    
    You think? I thought debian didn't package Go applications as they want to be able to build packages for the full dependency chain, and that's not tenable for Go.
    
    mperham
    
    One can still package Go binaries yourself. I do (and use upx too).
    
    sigio
    
    Debian (the distro) might not, but many projects make their own deb packages
    
    ptman
    
    many are packaged https://packages.debian.org/trixie/hugo
    
    mariusor
    
    OK, cool, I must be misremembering. :)
    
    vbernat
    
    I tried to avoid indirectly using reflect.GetMethodByName, but there is still a lack of awareness. Sometimes, it could be trivially avoided but maintainers may just not care at all. Forking a dependency is not easy in Go (in JS, you can patch them easily).
    
    carter2099
    
    Not that you were implying this, but:
    
    Forking a dependency is not easy in Go
    
    Feels more like a feature than a blocker. I'm new to Go though, and have Ruby experience, so monkey patching is something I'm used to but I often feel like I'm cheating a proper approach when doing so.