CODEWITHSUNDEEP
clinuxembeddedshared-libraries
Paul Praet
Paul Praet

Reputation: 1387

Shared objects overhead

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

Upvotes: 8

Views: 3078

Answers (3)

R.. GitHub STOP HELPING ICE
R.. GitHub STOP HELPING ICE

Reputation: 215259

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.

Upvotes: 13

Kevin Vermeer
Kevin Vermeer

Reputation: 2842

Unless memory is extremely tight, the size of one copy of these files is not the primary determining factor. Given that this is an embedded system, you probably have a good idea of what applications will be using your libraries and when. If your application opens and closes the multiple libraries it references dutifully, and you never have all the libraries open simultaneously, then the shared library will be a significant savings in RAM.

The other factor you need to consider is the performance penalty. Opening a shared library takes a small (usually trivial) amount of time; if you have a very slow processor or hard-to-hit real-time requirements, the static library will not incur the loading penalty of the shared library. Profile to find whether this is significant or not.

To sum up, shared libraries can be significantly better than static libraries in some special cases. In most cases, they do little to no harm. In simple situations, you get no benefit from shared libraries.

Of course, the shared library will be a significant savings in Flash if you have multiple applications (or versions of your application) which use the same library. If you use a static library, one copy (which is about the same size as the shared library[1]) will be compiled into each. This is useful when you're on a PC workstation. But you knew that. You're working with a library which is only used by one application.

[1] The memory difference of the individual library files is small. Shared libraries add an index and symbol table so that dlopen(3) can load the library. Whether or not this is significant will depend on your use case; compile for each and then compare the sizes to determine which is smaller in Flash. You'll have to run and profile to determine which consumes more RAM; they should be similar except for the initial loading of the shared library.

Upvotes: 6

Some programmer dude
Some programmer dude

Reputation: 409176

Having lots of libraries of course means more meta-data must be stored, and also some of that meta-data (library section headers etc.) will need to be stored in RAM when loaded. But the difference should be pretty negligible, even on (moderately modern) embedded systems.

I suggest you try both alternatives, and measure the used space in both FLASH and RAM, and then decide which is best.

Upvotes: 1

Related Questions