4 ms·

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 t

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

by tribaal 11y ago

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.