3 ms·

Shared object libraries are incredibly useful because they save memory and CPU resources. Cloning the process space during a fork(2) call, initializing structur

Shared object libraries are incredibly useful because they save memory and CPU resources. Cloning the process space during a fork(2) call, initializing structures, then context switching and whatnot is incredibly expensive.

coldtea 7y ago
>Cloning the process space during a fork(2) call, initializing structures, then context switching and whatnot is incredibly expensive. Err, we're running Electron apps today, with a full blown embedded browser engine, a vm, and a hellish complex DOM for rendering. Others run apps inside containers, with their own basic OS and standard libs -- compared to that the above is negligible.
- saagarjha 7y ago
  > we're running Electron apps today Some of us try not to on the belief that they don't perform acceptably.
- bayareanative 7y ago
  Nope. A strawman wrong doesn't justify anything related to the topic. fork() duplicates everything, which maybe overkill, which is why pthreads and vfork+exec also exist.
  - notacoward 7y ago
    That's not why pthreads exist, and vfork barely does. Pthreads exist to facilitate parallel operation (hence the name) on shared data, not as an efficiency measure. As for vfork, it has been deprecated since every UNIX implementation started marking pages as copy-on-write instead of actually copying. I was doing some of that work myself in 1990-91, so it's hardly new. The real problems with static linking don't have to do with fork, except in the sense of increasing reliance on VM overcommit (which IMO is a bad idea already). It's more to do with masking reuse of the same library across unrelated processes, as an efficiency issue but even more importantly in terms of tracking dependencies and updating software. No matter how good your configuration management (or similar mechanism) is, rebuilding large-N statically linked executables is less efficient and more error-prone than using the same information to update small-N shared libraries.
- imtringued 7y ago
  You can usually avoid this problem by using the web version of Slack, Discord, Rocketchat, etc. A single browser running everything is obviously more efficient than running ten.
_rtld_global_ro 7y ago
shared library can be expensive as well, the dynamic symbol lookup could be a lot more expensive than people would assume.
- notacoward 7y ago
  Correct. Shared libraries trade away CPU for memory. Even with some benefits in terms of cache warmth, the extra indirection and loader/VM complexity make shared libraries a net loss in terms of CPU.

coldtea 7y ago

>Cloning the process space during a fork(2) call, initializing structures, then context switching and whatnot is incredibly expensive. Err, we're running Electron apps today, with a full blown embedded browser engine, a vm, and a hellish complex DOM for rendering. Others run apps inside containers, with their own basic OS and standard libs -- compared to that the above is negligible.

saagarjha 7y ago
> we're running Electron apps today Some of us try not to on the belief that they don't perform acceptably.
bayareanative 7y ago
Nope. A strawman wrong doesn't justify anything related to the topic. fork() duplicates everything, which maybe overkill, which is why pthreads and vfork+exec also exist.
- notacoward 7y ago
  That's not why pthreads exist, and vfork barely does. Pthreads exist to facilitate parallel operation (hence the name) on shared data, not as an efficiency measure. As for vfork, it has been deprecated since every UNIX implementation started marking pages as copy-on-write instead of actually copying. I was doing some of that work myself in 1990-91, so it's hardly new. The real problems with static linking don't have to do with fork, except in the sense of increasing reliance on VM overcommit (which IMO is a bad idea already). It's more to do with masking reuse of the same library across unrelated processes, as an efficiency issue but even more importantly in terms of tracking dependencies and updating software. No matter how good your configuration management (or similar mechanism) is, rebuilding large-N statically linked executables is less efficient and more error-prone than using the same information to update small-N shared libraries.
imtringued 7y ago
You can usually avoid this problem by using the web version of Slack, Discord, Rocketchat, etc. A single browser running everything is obviously more efficient than running ten.

_rtld_global_ro 7y ago

shared library can be expensive as well, the dynamic symbol lookup could be a lot more expensive than people would assume.

notacoward 7y ago
Correct. Shared libraries trade away CPU for memory. Even with some benefits in terms of cache warmth, the extra indirection and loader/VM complexity make shared libraries a net loss in terms of CPU.