Compiled binary is large relative to gojq and jq
kklingenberg opened this issue · comments
Compiling 1.0.0-beta
on linux targeting glibc produces a binary of ~9 MB, much larger than jq and gojq. This might be an issue in some scenarios.
If reducing the binary size is in any way relevant to/aligned with the project's goals, I'd advice to look into compilation flags, stripping, and using UPX. Also, perhaps include those post-processing steps during "official compilation" as in #102.
A good example for this, I think, is pueue's workflow (https://github.com/Nukesor/pueue/blob/27a650e822969495f94071b846a334e869f3145b/.github/workflows/package-binary.yml) which uses svenstaro/upx-action@v2
to apply UPX compression to the binary.
I now made the build strip the binary by default in 722e5a2.
This reduces the file size to about 4 MB.
I also tried lto = true
, but this decreased the binary size by only about 100 KB while increasing the build time by about 50% on my machine.
Other things that could be tried: https://darkcoding.net/software/a-very-small-rust-binary-indeed/
Things like opt-level = "z"
might be worthwhile, but require some before-after benchmark to ensure that performance does not regress.
The same goes for something like UPX.
I'm closing this since you dealt with 50% of the size through stripping, and anything else is very likely to impact start-up time considerably. Thanks!
It is worth noting that lto = true
can also improve the performance. Increased build time might not be a problem since you compile only once in release mode.
It is worth noting that
lto = true
can also improve the performance. Increased build time might not be a problem since you compile only once in release mode.
I unfortunately cannot remember whether I benchmarked an LTO build, but I definitely compile more than once in release mode, because I perform benchmarks for most changes. If I have to wait 50% longer for a release build before each benchmark, then I will not benchmark so much in practice, leading probably to degraded performance. ;)