2

标题几乎概括了整个故事，我正在读这个，关键是

更大的可执行文件意味着更多的缓存未命中

并且由于静态可执行文件的定义大于动态链接的可执行文件，因此我很好奇在这种情况下的实际考虑因素是什么。

4

2 回答 2

3

链接中的文章讨论了在操作系统内核中内联小函数的副作用。这确实对性能产生了显着影响，因为在整个系统调用序列中，从许多不同的地方调用了同一个函数——例如，如果你调用open, 然后调用read, seek write，open将在内核的某个地方存储一个文件句柄，并且在必须“找到”对read、seek和的调用。write如果这是一个内联函数，我们现在在缓存中拥有该函数的三个副本，并且调用和read调用相同的函数完全没有任何好处。如果它是一个“非内联”函数，它确实会在缓存中准备好并调用该函数。seekwriteseekwrite

对于一个给定的进程，无论代码是静态链接还是动态链接，一旦应用程序完全加载，影响很小。如果应用程序有很多副本，那么其他进程可能会受益于为共享库重用相同的内存。但是该进程所需的大小保持不变，无论它与 0、1、3 还是 100 个其他进程共享。在许多可执行文件之间共享二进制文件的好处来自于系统中几乎每个可执行文件背后的 C 库之类的东西 - 因此，当您在系统中运行 1000 个进程时，所有进程都使用相同的基本运行时系统，有只有一份而不是 1000 份代码。但它不太可能对任何特定应用程序的缓存效率产生太大影响——可能是常见的功能，如strcpy诸如此类的使用频率很高，以至于当操作系统任务切换时，当下一个应用程序切换时，它仍然在缓存中的可能性很小strcpy。

所以，总而言之：可能根本没有任何区别。

于 2013-06-15T16:13:39.620 回答
3

静态版本的整体内存占用与动态版本相同；请记住，动态链接的对象仍然需要加载到内存中！

当然，也有人会争辩说，如果有多个进程在运行，并且它们都动态链接到同一个对象，那么内存中只需要一个副本，因此总占用空间比它们都静态链接时要低。

[免责声明：以上所有内容都是有根据的猜测；我从未测量过链接对缓存行为的影响。]

于 2013-06-15T16:04:36.573 回答