我很好奇，如果一个可执行文件写得不好，它有很多死代码，在外部引用了 1000 多个函数(即 .so 文件)，但在运行时实际上只调用了 100 个函数，那么 LD_BIND_NOW=1 会比LD_BIND_NOW 未设置？因为Procedure Linkage Table会包含900个无用的函数地址？在内存占用和性能方面更糟糕(因为我不知道查找是否为 O(n))。
我正在尝试查看将 LD_BIND_NOW 设置为 1 是否有帮助(通过与未设置的 LD_BIND_NOW 进行比较):
1. 在延迟方面 24 x 5 运行的程序
2. 在我的例子中，节省 1 微秒被认为是很大的，因为在程序生命周期内执行的代码路径主要是处理来自 TCP/UDP/共享内存的传入消息，然后对它们进行一些计算；
所有这些代码路径都需要很短的时间(例如 < 10 微秒)并且这些代码路径将运行数百万次
LD_BIND_NOW=1 是否有助于启动时间对我来说并不重要。
最佳答案
saving 1 microsecond is considered big in my case as the executions by the program are all short (e.g. <10 micro)
这不太可能(或者你的意思是别的)。一个典型的调用 execve(2) - 用于启动程序的系统调用 - 通常持续几毫秒。因此，程序在微秒内执行(从 execve 到 _exit(2))的情况很少见(而且几乎不可能)。
我建议你的程序每秒启动次数不要超过几次。如果整个程序确实非常短暂(因此它的 process 只持续几分之一秒)，您可以考虑其他一些方法(也许让服务器运行这些功能)。
LD_BIND_NOW 将影响(并减慢)启动时间(例如在动态链接器中 ld-linux(8) )。一些 event loop 的稳态执行时间应该无关紧要(缓存效果除外)。 .
另请参阅 this related answer 中的引用资料(针对不同问题)，它们包含与您的问题相关的详细解释。
简而言之，LD_BIND_NOW 的设置不会显着影响在紧密事件循环中处理每条传入消息所需的时间。
在某些情况下，在共享库(包含 position-independent code)中调用函数可能会稍微慢一些(最多几个百分点，在 x86-64 上可能更少)。您可以尝试静态链接，甚至可以考虑链接时间优化(即编译并链接您的所有代码 - 主程序和静态库 - 如果使用 -flto -O2 GCC ).
您可能已经积累了 technical debt , 你可能需要专业 code refactoring (这需要花费大量时间和精力，您应该预算)。
关于c++ - LD_BIND_NOW 可以使可执行文件运行更慢吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48109146/