Reducing Tailscale’s binary size on macOS(tailscale.com)
tailscale.com
Reducing Tailscale’s binary size on macOS
https://tailscale.com/blog/macos-binary-size/
7 comments
Generally on Apple platforms the move here would be putting the shared binary into a dynamic .framework rather then trying to eliminate the shared dependency. Is this a limitation of authoring it in Go that it has to be entirely static?
(I’m the author of the post)
The solution we ended up with was partially a matter of the minimum change to fix the issue, and partly because we have a lot of platforms to cover with a small team, so the fewer platform-specific concepts we have (frameworks in this case), the easier it is to maintain.
The solution we ended up with was partially a matter of the minimum change to fix the issue, and partly because we have a lot of platforms to cover with a small team, so the fewer platform-specific concepts we have (frameworks in this case), the easier it is to maintain.
As a user I’d prefer faster startup over shaving off a couple MB tbh.
Calling dlopen is perhaps one of the slowest way to bring in libraries on Darwin.
What would you recommend? dlopen is only used when running in CLI mode (which is not super performance sensitive), but not making it slower than it needs to be would be good too.
You should link against the library directly. dyld’s optimizations are complex, especially when it comes to third party code, but by linking directly the system can cache some of the work.
It could also be a legacy of a lot of the team coming from Google, which statically links everything except glibc.
As a Tailscale user, nice work! I applaud the effort and appreciate the result.
I'm surprised they didn't go for the binary size analysis tools like
https://github.com/google/bloaty
Or goweight.
https://github.com/google/bloaty
Or goweight.
I seem to remember reading that upx had a performance impact (startup times?).
@mihaip, have you been able to measure any changes before/after?
@mihaip, have you been able to measure any changes before/after?
upx is not used in the macOS build (we only mention it as a possibility in https://tailscale.com/kb/1207/small-tailscale/, which is for embedded systems), so I have no done any benchmarking with it.
Guys, please figure out a way to reduce your footprint on openwrt.
11452 -rwxr-xr-x 1 root root 11.2M Sep 1 2021 /usr/sbin/tailscaled
7612 -rwxr-xr-x 1 root root 7.4M Sep 1 2021 /usr/sbin/tailscale
I love tailscale, but it forces me to use usb sticks on most of my openwrt routers.
11452 -rwxr-xr-x 1 root root 11.2M Sep 1 2021 /usr/sbin/tailscaled
7612 -rwxr-xr-x 1 root root 7.4M Sep 1 2021 /usr/sbin/tailscale
I love tailscale, but it forces me to use usb sticks on most of my openwrt routers.
There is a way to build an even smaller version of Tailscale for embedded systems, though there are some trade offs with regards to ease of use and security. https://tailscale.com/kb/1207/small-tailscale/ has more details.
Method described gets most of the win from UPX.
That's not applicable on openwrt as it already uses lzma on filesystem level. Switching to UPX would cause excessive ram usage as binary would be in anonymous memory and no longer be backed by filesystem pages.
[deleted]
Somewhat tangential, but ever since a recent update of the MacOS tailscale client, I've been unable to connect to any other exit nodes. I click on the exit node I'd like to connect to and it just silently fails. I tried making a shortcut as well that would connect to that node and it also fails. I've verified the exit node itself is working correctly on other devices, it only fails on the Macbook.
Has anyone else encountered this issue?
Has anyone else encountered this issue?
One change that went into 1.36 is that you can no longer use an exit node while advertising one (https://github.com/tailscale/tailscale/issues/3569). The Mac UI was not updated for that in time, but the next release the menu items should be disabled correctly.
Can you sent a message to [email protected] about this and include a bug report ID (option click on the Tailscale menu icon and choose Debug -> Bug Report…)?
[deleted]
1.5 MB for a stub binary which does nothing but load and call a symbol from another file seems a little excessive in its own right.
That's pretty normal for statically linked executables unless you're aggressively stripping and removing things (which is hard to do)
Agreed. Strangely discussions of bloat sometimes trigger snarky replies:
https://news.ycombinator.com/item?id=34732782
https://news.ycombinator.com/item?id=34732782
bloated is relative and subjective but the only context where an 11MB binary could be considered bloated is embedded
hard to take seriously the idea that 11MB is bloated in a normal linux server or user desktop environment
hard to take seriously the idea that 11MB is bloated in a normal linux server or user desktop environment
If the program in intended by me to run on a small form factor computer with limited storage, such as a router, then the program nearly doubling in size is going to draw attention.
[deleted]