4 ms·
And if you can spare an extra ~150ms startup time: https://blog.filippo.io/shrink-your-go-binaries-with-this-one-weird-trick/ https://blog.filippo.io/shrink-yo
by pstuart 5y ago
And if you can spare an extra ~150ms startup time:
https://blog.filippo.io/shrink-your-go-binaries-with-this-one-weird-trick/ https://blog.filippo.io/shrink-your-go-binaries-with-this-on...
- latchkey 5y agoThat article is about -s -w and goupx. goupx is not necessary after go 1.6. https://github.com/pwaller/goupx#update-20160310 https://github.com/pwaller/goupx#update-20160310
- sugarkjube 5y agogoupx isn't. upx still is.
- deleted 5y ago[deleted]
- pstuart 5y agoIt's actually about upx, which is still relevant. I didn't notice the goupx bit but it doesn't diminish the value of upx, which was my intention in sharing.
- newman314 5y agoSerious question: Is upx worth the tradeoff in 2022? Trying to decide if it's worth working into the containers that I maintain.
- dlor 5y agoProbably not for Go in containers since binaries end up compressed anyway as part of the OCI layers. But Go binaries do get quite large so if you're distributing them other ways, it might be useful.
- mkdirp 5y agoI totally understand removing annotations in the DWARF tables since they're not really needed in a production environment, but why would you want to remove stack traces? They provide invaluable information in a production system, and removing them increases the start up time with negligible difference. In reality you'll tell whatever deployment system to deploy your binary/container, and you'll just wait until it's done. In such cases, 150ms won't make a difference in the grand scheme of things due to other systems such as your CI and other things in your pipeline.
- pstuart 5y agoI must confess to copypasta for this approach. Yes, stack traces are incredibly valuable. The upx compression itself does seem to be a no-brainer with the exception of any situation where that 150ms time actually matters.