| Updated: October 28, 2024 |
Shared libraries take time to load. When an application is linked to a shared object, the process loader first checks whether that shared object is already loaded.
If it isn't, the loader must first load the object out of permanent storage (IFS, EFS, or elsewhere). The process of loading the various ELF sections from the file can take time. The dynamic linker must look up the symbol names to get the appropriate addresses.
For a large shared object, it can be significantly quicker to statically link the application with the largest libraries because a static link links only the parts of the library that are used. By following this practice, you pay for the linker lookup penalties at compile time rather than at runtime. Another advantage of using statically linked libraries for your splash screen application is that it pulls only the necessary parts of the libraries into the splash screen application, which can potentially help reduce the size of your primary IFS.
Of course, because you'll need to statically link that library across multiple applications, statically linking an executable might consume more flash memory when multiple applications must make calls to the same library. In addition, this practice may introduce version incompatibilities between applications, if the shared library changes and you don't rebuild everything that it's linked against. In some systems, the performance benefits outweigh the drawbacks, however.
For more information about static and dynamic linking, see the Dynamic Linking chapter in System Architecture.