我很好奇如果一个可执行文件编写得很糟糕，它有很多死代码，在外部引用了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是否有助于启动时间对我无关紧要。
答案 0 :(得分：1)
在我的情况下，节省1微秒被认为很大，因为程序的执行都很短（例如<10微米）
这不太可能（或者你的意思是其他的）。对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上可能更少）。您可以尝试静态链接，如果使用GCC，您甚至可以考虑链接时间优化（即编译并链接所有代码 - 主程序和静态库 - 与-flto -O2）
您可能累积了technical debt，并且您可能需要专业code refactoring（这需要花费大量时间和精力，您应该预算）。