Open
Description
The current executable size is about 20MB on Windows, and slightly smaller on other platforms. While it is not a deal breaker, it wouldn't hurt to review the build process to see if the executable size could be reduced with compilation options.
- Look for common build options (optimize for size, trim debug symbols)
- Look at the list of dependencies and see which ones contribute to the bloat
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
dopey commentedon Oct 9, 2020
via @awakecoding in gitter - https://medium.com/@jmrobles/gos-best-friend-upx-the-executable-compressor-e4f4872f1d8a
dopey commentedon Oct 13, 2020
To follow up here - we don't have any immediate plans to work on reducing the size of the executable. However, the build process is all committed in Makefiles in this repo, so if anyone from the community would like to open a PR, we'd happily take the submission.
Glandos commentedon Mar 4, 2022
I have some small tests results.
First, sizes:
The first on is the binary extracted from .deb.
Second one is stripped with
strip -s
.Third one is
upx --ultra-brute
on the stripped version that took 10 minutes (yes, that's very long).Fourth one is
upx -1
on the stripped version that took less than 2 seconds.Fifth one is
xz -9
on the stripped version.Now for launch timing:
So the result is that if RPM and DEB are compressed with XZ, this is fine. The size on disk will be a little bit bigger, but it's usually harmless.
I've noticed that the current DEB version is using gzip, that should be changed.
You should at least strip binary to have a quick 10% on size. But then, debugging is harder.
UPX can be used, but it really slows down binary start.
dopey commentedon Mar 10, 2022
Hey, thanks for posting this @Glandos! It's great to have some concrete numbers.
So we are aware that the executable size is relatively large for
cli
. However, that comes with the territory - statically linked golang binaries. We could strip it down but we'd be losing the debugging facilities you mentioned, and we'd prefer not to do that - at least not by default. We'd be happy to have a target added to the makefile that could build a reduced size executable.Furthermore, we'd like to understand the case better (beyond just smaller is better).
ssh
we could remove those libraries, or libraries for OTT, etc.