一般认为静态库的性能优于动态库。我的问题是:它是否也取决于 dll 是否已加载到内存中？我的意思是，一旦初始化和所有事情都发生了，动态库的函数调用和执行时间是否比静态库更长？
最佳答案
免责声明:我是一个 Linux-fu 蚱蜢，所以这里和那里(或到处)可能会有一些不准确之处。不过大体思路应该是比较正确的。如果不是，我相信优秀的 SO 人员会很快纠正我。 :-)
哦，我提供的链接是以 Windows 为中心的。如果有人可以提供适当的以 Linux 为中心的链接，我将不胜感激。
简短回答:可能。然而，即使是这样，性能差异也确实可以忽略不计。
当您链接静态库时，编译器会生成代码来直接执行所有函数调用。创建进程并执行该代码时，函数调用是一个简单的调用指令。
当您使用动态库时，成本取决于您使用的是加载时动态链接还是运行时动态链接。
与 load-time dynamic linking ，编译器仍然生成代码来直接调用该函数，就好像它是静态链接一样。当进程加载器加载 DLL 时，它会调用运行时链接器来修复进程内存，以便这些调用直接转到实际的函数实现。这必须在对已加载库中的函数进行任何调用之前发生。在 Windows 上，它由 NT DLL 加载器完成，它在进程初始化时调用 DLL 上的 LoadLibrary。在 Linux 上，它由运行时链接器 ld-linux.so 完成。
与 /DELAYLOAD load-time dynamic linking，这个过程本质上是一样的，除了编译器生成代码调用小 stub ，这将检查库是否被加载，如果没有，将调用 NT DLL 加载器。因此，DLL 将按需加载，进程加载器不必在进程初始化时加载它。这导致进程启动时间更快，但调用性能仍然相同。 (但是请注意，延迟加载还有其他缺点)
我不知道是否有相应的 Linux 支持，但如果没有，我会感到惊讶。
与 run-time dynamic linking ，您的代码维护函数指针并决定何时加载库。在 Windows 上，它必须使用 LoadLibrary 和 GetProcAddress，在 Linux 上它是 dlopen、dlsym 和 dlclose。在任何情况下，对进程启动时间的影响都与延迟加载加载时动态链接相同；然而，在每个方法调用上取消引用指针确实增加了一个可以忽略不计的小成本。 (虽然如果你知道自己在做什么，你可能会发疯并修复你的进程内存以避免指针取消引用。然而，正确地做到这一点的努力比你将获得的性能 yield 大一个数量级它。)
关于windows - 静态库与动态库性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4384752/