5 ms·

Reducing Tailscale’s binary size on macOS

131 points by notpushkin 4y ago

tarasglek 4y ago
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.
- mihaip 4y ago
  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/ https://tailscale.com/kb/1207/small-tailscale/ has more details.
  - tarasglek 4y ago
    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 4y ago
  [deleted]
newman314 4y ago
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 4y ago
  upx is not used in the macOS build (we only mention it as a possibility in https://tailscale.com/kb/1207/small-tailscale/ https://tailscale.com/kb/1207/small-tailscale/, which is for embedded systems), so I have no done any benchmarking with it.
duskwuff 4y ago
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.
- 1vuio0pswjnm7 4y ago
  Agreed. Strangely discussions of bloat sometimes trigger snarky replies: https://news.ycombinator.com/item?id=34732782 https://news.ycombinator.com/item?id=34732782
  - preseinger 4y ago
    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
    - 1vuio0pswjnm7 4y ago
      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.
- mihaip 4y ago
  The main binary also contains Tailscale’s GUI (onboarding, auth, menu, notifications, etc) so it does a little more than that.
  - mrpippy 4y ago
    Plus, it's a universal binary with x86_64 and arm64 slices.
  - duskwuff 4y ago
    Oh, if that's the case then 1.5 MB seems much more reasonable. Never mind.
- deleted 4y ago
least 4y ago
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?
- deleted 4y ago
  [deleted]
- mihaip 4y ago
  Can you sent a message to support@tailscale.com about this and include a bug report ID (option click on the Tailscale menu icon and choose Debug -> Bug Report…)?
- mihaip 4y ago
  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 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.
ysleepy 4y ago
I'm surprised they didn't go for the binary size analysis tools like https://github.com/google/bloaty https://github.com/google/bloaty Or goweight.
zacwest 4y ago
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?
- manmal 4y ago
  As a user I’d prefer faster startup over shaving off a couple MB tbh.
  - hansvm 4y ago
    Even if so that takes benchmarking on the target systems. Linking can be fast compared to reading a few extra MB from disk.
    - manmal 4y ago
      With SSDs approaching 10GB/s reads, I think that’s negligible. Also, chances are high the binary is in RAM for a long time after first use.
  - saagarjha 4y ago
    Calling dlopen is perhaps one of the slowest way to bring in libraries on Darwin.
    - mihaip 4y ago
      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.
      - saagarjha 4y ago
        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.
CharlesW 4y ago
As a Tailscale user, nice work! I applaud the effort and appreciate the result.

131 points by notpushkin 4y ago

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.

mihaip 4y ago
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/ https://tailscale.com/kb/1207/small-tailscale/ has more details.
- tarasglek 4y ago
  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 4y ago
[deleted]

newman314 4y ago

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 4y ago
upx is not used in the macOS build (we only mention it as a possibility in https://tailscale.com/kb/1207/small-tailscale/ https://tailscale.com/kb/1207/small-tailscale/, which is for embedded systems), so I have no done any benchmarking with it.

duskwuff 4y ago

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.

1vuio0pswjnm7 4y ago
Agreed. Strangely discussions of bloat sometimes trigger snarky replies: https://news.ycombinator.com/item?id=34732782 https://news.ycombinator.com/item?id=34732782
- preseinger 4y ago
  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
  - 1vuio0pswjnm7 4y ago
    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.
mihaip 4y ago
The main binary also contains Tailscale’s GUI (onboarding, auth, menu, notifications, etc) so it does a little more than that.
- mrpippy 4y ago
  Plus, it's a universal binary with x86_64 and arm64 slices.
- duskwuff 4y ago
  Oh, if that's the case then 1.5 MB seems much more reasonable. Never mind.
deleted 4y ago

least 4y ago

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?

deleted 4y ago
[deleted]
mihaip 4y ago
Can you sent a message to support@tailscale.com about this and include a bug report ID (option click on the Tailscale menu icon and choose Debug -> Bug Report…)?
mihaip 4y ago
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 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.

ysleepy 4y ago

I'm surprised they didn't go for the binary size analysis tools like https://github.com/google/bloaty https://github.com/google/bloaty Or goweight.

zacwest 4y ago

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?

manmal 4y ago
As a user I’d prefer faster startup over shaving off a couple MB tbh.
- hansvm 4y ago
  Even if so that takes benchmarking on the target systems. Linking can be fast compared to reading a few extra MB from disk.
  - manmal 4y ago
    With SSDs approaching 10GB/s reads, I think that’s negligible. Also, chances are high the binary is in RAM for a long time after first use.
- saagarjha 4y ago
  Calling dlopen is perhaps one of the slowest way to bring in libraries on Darwin.
  - mihaip 4y ago
    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.
    - saagarjha 4y ago
      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.

CharlesW 4y ago

As a Tailscale user, nice work! I applaud the effort and appreciate the result.