C++ _dl_runtime_resolve——何时将共享对象加载到内存中？
我们有一个高性能要求的消息处理系统。最近我们注意到，第一条消息比后续消息花费的时间要长很多倍。在我们的系统中进行一系列转换和消息扩充，其中大部分是通过外部库完成的 我刚刚分析了这个问题（使用callgrind），比较了一条消息的“运行”与多条消息的“运行”（提供了比较基准） 我看到的主要区别是函数“do_lookup_x”占用了大量时间。查看对该函数的各种调用，它们似乎都是由公共函数调用的：_dl_runtime_resolve。不知道这个函数做什么，但对我来说，这看起来像是第一次使用各种共享库，然后由ld加载到内存中 这是正确的假设吗？二进制文件不会将共享库加载到内存中，直到它们准备好使用，因此我们会在第一条消息上看到一个巨大的减速，但在随后的消息上没有 我们如何避免这种情况 注：我们在微秒级上操作。从C++ _dl_runtime_resolve——何时将共享对象加载到内存中？,c++,linux,ld,C++,Linux,Ld,我们有一个高性能要求的消息处理系统。最近我们注意到，第一条消息比后续消息花费的时间要长很多倍。在我们的系统中进行一系列转换和消息扩充，其中大部分是通过外部库完成的 我刚刚分析了这个问题（使用callgrind），比较了一条消息的“运行”与多条消息的“运行”（提供了比较基准） 我看到的主要区别是函数“do_lookup_x”占用了大量时间。查看对该函数的各种调用，它们似乎都是由公共函数调用的：_dl_runtime_resolve。不知道这个函数做什么，但对我来说，这看起来像是第一次使用各种共享库
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\u BIND\u NOW=y./timesensitieapp-z now