And if you can spare an extra ~150ms startup time:

https://blog.filippo.io/shrink-your-go-binaries-with-this-on...

Serious question: Is upx worth the tradeoff in 2022?

Trying to decide if it's worth working into the containers that I maintain.

Probably 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.

I 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.

I 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.

That article is about -s -w and goupx.

goupx is not necessary after go 1.6. https://github.com/pwaller/goupx#update-20160310

It'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.

goupx isn't. upx still is.

Doesn't that make crashes much more difficult to debug? Or can you re-attach this information later on if you get a crash report?

I mean sure, in theory you shouldn't get any of those in production, but no software is perfect.