我们有一个具有高性能要求的消息处理系统。最近我们注意到第一条消息比后续消息花费的时间要长很多倍。当这通过我们的系统时，会发生一堆转换和消息增强，其中大部分是通过外部库完成的。
我刚刚分析了这个问题（使用 callgrind），将仅一条消息的“运行”与许多消息的“运行”进行比较（提供比较的基线）。
我看到的主要区别是函数“do_lookup_x”占用了大量时间。查看对该函数的各种调用，它们似乎都是由通用函数调用的：_dl_runtime_resolve。不确定这个函数是做什么的，但对我来说，这看起来像是第一次使用各种共享库，然后被 ld 加载到内存中。
这是一个正确的假设吗？二进制文件在准备使用共享库之前不会将它们加载到内存中，因此我们将看到第一条消息的速度大幅下降，但随后的消息都没有？
我们如何避免这种情况？
注意：我们在微秒级进行操作。
从ld.so(8)手册页的ENVIRONMENT部分：
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。
作为Ignacio Vazquez-Abrams 的运行时建议的替代方案，您可以在链接时执行相同的操作。链接共享库时，将-z now标志传递给链接器。