3 ms·

Not gonna burn your karma, however: a) You are failing to account for the bloat caused by the presence of the dynamic linker, the dynamic loader, all the code

Not gonna burn your karma, however: a) You are failing to account for the bloat caused by the presence of the dynamic linker, the dynamic loader, all the code that must operate under the assumptions of a dynamically linked environment, and the various auxiliaries used to treat shared library hell issues like WinSxS and libtool. b) Most modern static linking implementations do things like sharing of text segments across processes and other dedup techniques, so they're not actually that bloated at all.

tribaal 11y ago
So maybe my comment stems from ignorance. Are you saying that two Golang projects sharing the same (large, for the sake of the argument) dependency would not take (size of the dependency * 2) on i.e. the Ubuntu live CD (as was the example in the fine article)?
- ajuc 11y ago
  You have program X, and Y, both depending on big library L with 1000 symbols. X uses 1 symbol l1 from L, Y use another symbol l2 from L. With dynamic linking you need the whole library, no matter how much of it you use. With static linking (and --gc-sections -fdata-sections) you have parts of L compiled into X and Y binaries, but just the functions used (and their dependencies). It's possible that l1 and l2 share dependencies - and these will be duplicated. But still static linking is likely to be net win. Dynamic linking is mostly about maintanance.
- orbifold 11y ago
  A statically linked binary can in principle only include code from the libraries it actually needs, so the overhead for some programs can be quite small and not as large as you might imagine. It also reduces the memory footprint at runtime.
- TheLoneWolfling 11y ago
  Correct. I would not be surprised if those two Golang projects take less than the size of the dependency. 2x is a degenerate worst-case. With static linking, you only need to pull in things you actually need (and you can optimize from there!), whereas with dynamic linking you need to pull in the entire dependency regardless. (You only need to pull in one copy regardless of how many things are using the library, true. But you need to pull in one full copy always.) There are very few cases where you actually use the entire library in a project - and if you are indeed using an entire library in a project your project is necessarily large enough compared to the library that it's not much overhead percentage-wise.
  - tribaal 11y ago
    That makes a lot of sense. Thanks for the insight, I now understand why my comment was misguided.
david-given 11y ago
Regarding (b): do you have a pointer? I've never heard of this, and would be rather interested to know how it's done.

tribaal 11y ago

So maybe my comment stems from ignorance. Are you saying that two Golang projects sharing the same (large, for the sake of the argument) dependency would not take (size of the dependency * 2) on i.e. the Ubuntu live CD (as was the example in the fine article)?

ajuc 11y ago
You have program X, and Y, both depending on big library L with 1000 symbols. X uses 1 symbol l1 from L, Y use another symbol l2 from L. With dynamic linking you need the whole library, no matter how much of it you use. With static linking (and --gc-sections -fdata-sections) you have parts of L compiled into X and Y binaries, but just the functions used (and their dependencies). It's possible that l1 and l2 share dependencies - and these will be duplicated. But still static linking is likely to be net win. Dynamic linking is mostly about maintanance.
orbifold 11y ago
A statically linked binary can in principle only include code from the libraries it actually needs, so the overhead for some programs can be quite small and not as large as you might imagine. It also reduces the memory footprint at runtime.
TheLoneWolfling 11y ago
Correct. I would not be surprised if those two Golang projects take less than the size of the dependency. 2x is a degenerate worst-case. With static linking, you only need to pull in things you actually need (and you can optimize from there!), whereas with dynamic linking you need to pull in the entire dependency regardless. (You only need to pull in one copy regardless of how many things are using the library, true. But you need to pull in one full copy always.) There are very few cases where you actually use the entire library in a project - and if you are indeed using an entire library in a project your project is necessarily large enough compared to the library that it's not much overhead percentage-wise.
- tribaal 11y ago
  That makes a lot of sense. Thanks for the insight, I now understand why my comment was misguided.

david-given 11y ago

Regarding (b): do you have a pointer? I've never heard of this, and would be rather interested to know how it's done.