Shared objects overhead

Question

We have a very modular application with a lot of shared objects (.so). Some people argue that on low-end platforms with limited memory/flash, it is better to statically link everything into one big executable as shared objects have overhead.

What is your opinion on this ?

Best Regards,

Paul

Answer 1

The costs of shared libraries are roughly (per library):

• At least 4k of private dirty memory.
• At least 12k of virtual address space.
• Several filesystem access syscalls, mmap and mprotect syscalls, and at least one page fault at load time.
• Time to resolve symbol references in the library code.

Plus position-independent code costs:

• Loss of one general-purpose register (this can be huge on x86 (32bit) but mostly irrelevant on other archs).
• Extra level of indirection accessing global/static variables (and constants).

If you have a large long-running application, the costs may not matter to you at all, unless you're on a tiny embedded system. On the other hand, if you're writing something that may be invoked many times for short tasks (like a language interpreter) these costs can be huge. Putting all of the standard modules in their own .so files rather than static linking them by default is a huge part of why Perl, Python, etc. are so slow to start.

Personally, I would go with the strategy of using dynamic loaded modules as a extensibility tool, not as a development model.