Half the size of Go binaries you encounter in the wild are debugging symbols. Compile without them and use `upx --ultra-brute` and the binary will be about ~15% of its original size. You still get goroutine stack traces from panics without the debugging symbols.
Even building without debugging symbols, a lot of the remaining size comes from runtime type information and method/function/struct names, used in reflection, which there's no way to remove. That also has some reverse-engineering implications.
I didn't know go compiler allowed to build without those, thanks.
I've just tried on a go binary that was 2.4MO. After building it with `go build -ldflags=-s .`, it's 1.6MO. After stripping with upx, it's 480ko (and still works, and has panic stack traces).
Please note that upx also compresses your binary contents and decompresses it at runtime.
When downloading a WASM file over HTTP, the server can gzip it transparently. It'd be interesting to compare the effects on the size with what upx does (which is more specialized than gzip).
I see, thanks. I used vanilla `strip` on my binary and it did not produce any size gain (so the strip flag of go compiler is plenty enough).
Indeed, given how browsers already handle gunziping resources, it's probably best to rely on it. My binary, stripped by the go compiler and gziped, is 525ko (against 480ko using upx).
I remember UPX packed binaries would trigger some antivirus software in the past because packing was so frequently used by virus authors. Does anyone know if this is still the case?
Also, can you use UPX on WebAssembly binaries? If so, will that trigger any widely used antivirus software?
UPX just compresses the machine code on disk and decompresses it in memory before execution. WebAssembly executables are delivered via http and can just be compressed with gzip/brotli etc as part of the existing protocols, completely transparently to WA itself.
Granted, UPX is specialized so it might have a slight compression edge over gzip. But layering UPX over WA will require three passes over all the code before it's ready to start (1: browser downloads and executes UPX stub and compressed data. 2: UPX unpacks and reloads uncompressed code. 3: browser re-compiles and executes unpacked code again.) This would completely decimate browsers attempts to make WA startup fast like firefox's streaming compiler [1] that starts compiling it before it's even done downloading.
