我很好奇，如果一个可执行文件写得不好，它有很多死代码，指的是外部的 1000 个函数(即 .so 文件)，但这些函数中只有 100 个在运行时实际调用，LD_BIND_NOW=1 会比没有设置LD_BIND_NOW更糟糕吗？因为过程链接表将包含 900 个无用的函数地址？在内存占用和性能方面更糟(因为我不知道查找是否为 O(n))。
我正在尝试查看将 LD_BIND_NOW 设置为 1 是否有帮助(通过与未设置LD_BIND_NOW进行比较)：
1. 在延迟
方面运行 24 x 5 的程序 2. 在我的情况下，节省 1 微秒被认为是很大的，因为在程序生命周期内执行的代码路径主要是处理来自 TCP/UDP/共享内存的传入消息，然后对它们进行一些计算; 所有这些代码路径都需要非常短的时间(例如<10 微)，这些代码路径将像数百万次
一样运行
LD_BIND_NOW=1 是否有助于启动时间对我来说并不重要。
情况下节省 1 微秒被认为是很大的，因为程序的执行都很短(例如 <10 微)
这不太可能(或者你的意思是别的)。对 execve(2) 的典型调用 - 用于启动程序的系统调用 - 通常持续几毫秒。因此，程序在微秒内执行(从execve到_exit(2))是罕见的(实际上是不可能的)。
我建议你的程序每秒启动次数不要超过几次。如果整个程序确实非常短暂(因此它的过程只持续几分之一秒)，您可以考虑其他方法(也许使服务器运行这些功能)。
LD_BIND_NOW会影响(并减慢)启动时间(例如，在动态链接器 ld-linux(8) 中)。某些事件循环的稳定状态执行时间应该无关紧要(缓存效果除外)。
另请参阅此相关答案(针对其他问题)中的参考文献，它们包含与您的问题相关的详细说明。
简而言之，LD_BIND_NOW的设置不会显著影响在紧密事件循环中处理每条传入消息所需的时间。
在某些情况下，调用共享库(包含与位置无关的代码)中的函数可能会稍微慢一些(最多百分之几，在 x86-64 上可能更少)。您可以尝试静态链接，甚至可以考虑链接时间优化(即，如果使用GCC，则编译和链接所有代码 - 主程序和静态库 - 与-flto -O2)。
你可能已经积累了技术债务，你可能需要大量的代码重构(这需要大量的时间和精力，你应该预算)。