01mf02 / jaq

A jq clone focussed on correctness, speed, and simplicity

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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!

commented

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. ;)