_dl_runtime_resolve - 何时将共享对象加载到内存中？

Question

我们有一个具有高性能要求的消息处理系统。最近我们注意到第一条消息比后续消息长了许多倍。当这通过我们的系统时，发生了一堆转换和消息扩充，其中大部分是通过外部库完成的。

我只是简单地描述了这个问题（使用callgrind），将一条消息的“运行”与许多消息的“运行”进行比较（提供比较基线）。

我看到的主要区别是功能“do_lookup_x”占用了大量时间。查看对此函数的各种调用，它们似乎都由公共函数调用：_dl_runtime_resolve。不知道这个函数做了什么，但对我来说这看起来像是第一次使用各种共享库，然后由ld加载到内存中。

这是正确的假设吗？二进制文件在准备好使用之前不会将共享库加载到内存中，因此我们会看到第一条消息大幅减速，但后续没有？

我们如何避免这种情况？

注意：我们以微秒级进行操作。

Answer 1

从ld.so(8)手册页环境部分：

   LD_BIND_NOW
          (libc5;  glibc since 2.1.1) If set to a non-empty string, causes
          the dynamic linker to resolve all  symbols  at  program  startup
          instead  of deferring function call resolution to the point when
          they are first referenced.  This is useful when using  a  debug-
          ger.

所以，LD_BIND_NOW=y ./timesensitiveapp。

Answer 2

作为Ignacio Vazquez-Abrams's runtime suggestion的替代方案，您可以在链接时执行相同的操作。链接共享库时，将-z now标志传递给链接器。