From distributions where you build everything from source (most cloud providers today, mobile phone operators, etc), such advantages are purely theoretical & never play out in practice. In such environments you're pushing out updates of the entire system on whatever your regular cadence is. Additionally, because the old library is still mapped & running you have to know to restart all the processes that have the old version linked in. Not an easy task.
About the only place it kind of matters is Linux distros where you are deploying closed source binaries linked against system libraries. I'm not sure that's a significant use-case.
The only performance benefit is memory. If you have a core infrastructure library that's widely shared (e.g. libopenssl) then it can have some benefit. In practice I much prefer the microservice model with a formal IPC API. Then the SW update is trivial to fix the exploit - just kill the 1 process providing the service.
When I said mobile phone operators, I meant more Apple and Google, not the telecom operators. I haven't worked at telecom operators but I wouldn't be surprised if that world is wildly different - IT is generally considered a cost center rather than as way to remove costs in other parts of the org.
Apple, Google, Microsoft, Amazon, Facebook all build everything from source. Source: I worked at 3 of those & have friends coworkers at the rest. For cloud users I don't have as good a knowledge of that space. I imagine the majority of them use off-the-shelf prebuilt libraries that come with the OS they run on.
Suppose 100 processes on the same box call the same function in glibc. If each process had its own redundant version of it mapped into memory, then that's 100x more cache misses compared to them all sharing the same page.
I get that only a handful of libraries are actually used, but that's a very fat tail and the performance will be very bad if that handful of libraries are always statically linked. This may be less important if the program is in a container (isn't sharing anyway) or launched as an AWS Lambda throwaway. I dunno, maybe dynamic linking isn't relevant anymore now that most Linux programs are meant to run in containers on an expensive cloud with tons of memory.
> In practice I much prefer the microservice model with a formal IPC API.
This converts a simple and solved problem, sharing memory, to a client-server distributed systems problem. There is no need. It's all on the same box.
I would highly recommend you shift your thinking & consider even something as basic as threads as a distributed systems problem. The distributed systems field has a much richer successful history of how to design robust systems at scale (not just in terms of compute resources but also in terms of # of people working on the problem & number of components). Sharing memory is actually not a simple & solved problem but distributed systems problem generally have lots of formal methods & tools for dealing with unreliability of any given component.
That's also ignoring that measuring the distributed cost of a component is fundamentally simpler than measuring it for a library mapped into 50 million processes.
Shared libraries can be useful but their value is often vastly overstated.
About the only place it kind of matters is Linux distros where you are deploying closed source binaries linked against system libraries. I'm not sure that's a significant use-case.
The only performance benefit is memory. If you have a core infrastructure library that's widely shared (e.g. libopenssl) then it can have some benefit. In practice I much prefer the microservice model with a formal IPC API. Then the SW update is trivial to fix the exploit - just kill the 1 process providing the service.