Reducing Tailscale’s binary size on macOS | Hacker News Reader

Reducing Tailscale’s binary size on macOS

tailscale.com

131 pointsnotpushkin30 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?

It could also be a legacy of a lot of the team coming from Google, which statically links everything except glibc.

I'm surprised Google isn't using musl then at this point.

They were spearheading the LLVM libc project at one point, I'd assume they'd replace glibc with that if anything.

Musl is slow.

(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.

As a user I’d prefer faster startup over shaving off a couple MB tbh.

Even if so that takes benchmarking on the target systems. Linking can be fast compared to reading a few extra MB from disk.

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.

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.

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.

I seem to remember reading that upx had a performance impact (startup times?).

@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.

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.

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?

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…)?

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.

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.

Agreed. Strangely discussions of bloat sometimes trigger snarky replies:

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

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.

The main binary also contains Tailscale’s GUI (onboarding, auth, menu, notifications, etc) so it does a little more than that.

Plus, it's a universal binary with x86_64 and arm64 slices.

Oh, if that's the case then 1.5 MB seems much more reasonable. Never mind.

That's pretty normal for statically linked executables unless you're aggressively stripping and removing things (which is hard to do)

Reply on news.ycombinator.com