标题几乎概括了整个故事，我是reading this关键是
A bigger executable means more cache misses
并且由于静态可执行文件根据定义大于动态链接的可执行文件，我很好奇在这种情况下有哪些实际考虑因素。
最佳答案
链接中的文章讨论了在 OS 内核中内联小函数的副作用。这确实对性能产生了显着影响，因为在一系列系统调用中从许多不同的地方调用了相同的函数 - 例如，如果您调用 open，然后调用 read, seek write, open 将文件句柄存储在内核中的某处，并在对 read 的调用中>、seek 和write，必须“找到”该句柄。如果这是一个内联函数，我们现在在缓存中有该函数的三个拷贝，并且 read 调用与 seek 和 相同的函数没有任何好处写 确实如此。如果它是一个“非内联”函数，当 seek 和 write 调用该函数时，它确实会在缓存中准备就绪。
对于给定的进程，无论代码是静态链接还是动态链接，一旦应用程序完全加载，影响都非常小。如果应用程序有许多拷贝，那么其他进程可能会受益于为共享库重新使用相同的内存。但是无论它与 0、1、3 还是 100 个其他进程共享，该进程所需的大小都保持不变。在许多可执行文件之间共享二进制文件的好处来自系统中几乎每个可执行文件背后的 C 库之类的东西 - 因此当您在系统中运行 1000 个进程时，它们都使用相同的基本运行时系统，有只有一份而不是 1000 份代码。但它不太可能对任何特定应用程序的缓存效率产生太大影响 - 也许像 strcpy 这样的常用功能经常使用，以至于当操作系统任务切换时，它的可能性很小当下一个应用程序执行 strcpy 时仍在缓存中。
因此，总而言之:可能根本没有任何区别。
关于c++ - 由于缓存未命中，我应该避免静态编译吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17125477/