golang程序编译后，要不要用upx压缩？

之前golang编写的服务器端程序一直有用upx压缩的习惯，upx压缩后文件确实小了非常多，按默认的压缩级别其压缩率通常可以达到55%左右，如果按最高的级别upx -9则其压缩率更高（按我写的ssh tunnel代理程序，其压缩率达到30%）。
一直知道upx的压缩率很高，可以大大减小程序的大小，也知道用upx压缩的程序，在运行时须解压，cpu及内存会有所消耗，但是并不知道具体的情况。今天在mac m1芯片的机器上测试了下，下面是测试的过程。

本例中的程序是golang写的一个自用的ssh tunnel代理及端口转发程序

本例中用到的主要编译选项说明如下：

• -ldflags 'flag list'

  • '-s -w': 压缩编译后的体积
  • -s: 去掉符号表
  • -w: 去掉调试信息，不能gdb调试了
• -trimpath：删除Go编译文档的GOPATH信息

1. 编译选项及文件大小

• 去除符号表：CGO_ENABLED=0 GOARCH=amd64 go build -v -a -ldflags -s -installsuffix cgo -trimpath，编译完文件大小10.0m

• 去除符号表调试信息和：CGO_ENABLED=0 GOARCH=amd64 go build -v -a -ldflags "-s -w" -installsuffix cgo -trimpath（ldflags新增了-w参数：-ldflags "-s -w"），编译完文件大小7.7m

• -ldflags -s加upx压缩后文件大小5.9m

-ldflags -s -w加upx压缩后文件大小3.1m

1. 运行内存占用大小

• 不压缩情况下初始启动内存占用大小17.1m

• upx压缩后内存占用28.5m，观察了一段时间内存并没有降下来

1. 总结

在我的机器上（mac mini 2020 m1 16G）上的运行情况看，压缩确实可以大大减小文件大小，但是内存占用高了许多。对于我来说，比起文件大小占用的硬盘空间，我更在乎运行时的内存占用，你呢？

注：本文的测试的只是我运行的环境，不能代表linux或者windows也是有类似的结果，等以后有时间了我或许会对linux系统进一步做测试。

-ldflags "-s -w" + upx压缩后程序无法执行，会有下列错误：63302 segmentation fault /path/to/your/app，具体原因尚不知