隐式动态链接vs显式动态链接：哪种方式效率更高？

Great question—this is a common point of confusion when working with shared libraries on Linux, especially once you move past basic compile-time linking. Let’s break down the overhead differences in IO, CPU, and memory, and clarify which approach is better for different scenarios.

Core Background First #

Quick recap to align on terms:

• Implicit dynamic linking: You link against the library at compile time with -l<library> flags, and the Linux dynamic loader (ld-linux.so) automatically loads the .so into your process’s address space when the program starts.
• Explicit dynamic linking: You load the library manually at runtime using dlopen(), resolve symbols with dlsym(), and unload it with dlclose().

Overhead Comparison #

IO Overhead #

• Implicit linking: The loader maps the library’s necessary segments (like .text, .data) into memory at program startup. If multiple processes use the same .so, the kernel shares physical memory pages for read-only code segments, so the IO cost is amortized across processes. However, this happens upfront—though demand paging means actual physical IO only occurs when specific pages are accessed, not the entire library at once.
• Explicit linking: You control exactly when the library is loaded. For example, if you only need a library for a rare feature, you can load it only when that feature is triggered. This cuts down on startup-time IO, but adds IO overhead later when you call dlopen(). If your program uses the library throughout its runtime, total IO ends up roughly equivalent to implicit linking—just shifted in timing.

CPU Overhead #

• Implicit linking:
  • By default, Linux uses lazy binding: the loader resolves symbols (like function addresses) only the first time they’re called, not at startup. This minimizes startup CPU cost.
  • If you disable lazy binding (with -z now), the loader resolves all symbols upfront, which increases startup CPU time but eliminates runtime resolution delays.
  • The loader’s symbol resolution is optimized for bulk operations, so it’s efficient for large numbers of symbols.
• Explicit linking:
  • Each call to dlsym() requires a symbol lookup in the library’s symbol table, which has a small CPU cost per call. But if you cache the returned function pointer (store it in a variable and reuse it), this overhead disappears—subsequent calls to the function are identical in cost to implicit linking.
  • Explicit linking avoids any loader CPU overhead at startup for that library, which can be a big win if your program links against many libraries but only uses a few early on.

Memory Overhead #

• Implicit linking: The library is mapped into your process’s address space at startup, but demand paging means physical memory is only allocated for pages that are actually accessed. Read-only code segments are shared across processes, so no extra memory is used if another process already has the library loaded. Private data segments are duplicated per process, same as explicit linking.
• Explicit linking: Same shared memory behavior for code segments, but you can call dlclose() when you’re done with the library. This removes the mapping from your process’s address space, and if no other processes are using the library, the kernel can free the physical memory pages. For optional or short-lived features, this can reduce long-term memory footprint.

Which Is More Efficient? #

There’s no one-size-fits-all answer—it depends on your use case:

• Use implicit linking if: Your program relies on the library for core functionality that’s used throughout runtime. It’s simpler, and once the initial loading is done, runtime performance matches explicit linking (with cached pointers).
• Use explicit linking if: You’re working with optional features, plugins, or libraries that are only needed occasionally. It reduces startup time and resource usage, and lets you free memory when the library isn’t needed. Just remember to cache dlsym() results to avoid repeated lookup overhead.

内容的提问来源于stack exchange，提问作者xjk