5 ms·

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

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.
hn_go_brrrrr 4y ago
It could also be a legacy of a lot of the team coming from Google, which statically links everything except glibc.
- xxpor 4y ago
  I'm surprised Google isn't using musl then at this point.
  - favorited 4y ago
    They were spearheading the LLVM libc project at one point, I'd assume they'd replace glibc with that if anything.
  - saagarjha 4y ago
    Musl is slow.
mihaip 4y ago
(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.

5 ms·

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

by zacwest 4y ago

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.
hn_go_brrrrr 4y ago
It could also be a legacy of a lot of the team coming from Google, which statically links everything except glibc.
- xxpor 4y ago
  I'm surprised Google isn't using musl then at this point.
  - favorited 4y ago
    They were spearheading the LLVM libc project at one point, I'd assume they'd replace glibc with that if anything.
  - saagarjha 4y ago
    Musl is slow.
mihaip 4y ago
(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.