二进制文件的大小如何影响执行速度？具体来说，我说的是用 ANSI-C 编写的代码，使用 gnu 或 intel 编译器翻译成机器语言。二进制文件的目标平台是运行 Linux 操作系统的具有英特尔或 AMD 多核 CPU 的现代计算机。该代码可能使用 openMP 并行执行数值计算，二进制文件可能有几兆字节。
请注意，在任何情况下，执行时间都将远大于加载代码和库所需的时间。我想到了用于求解大型常微分方程系统的非常具体的代码，用于模拟动力学方程，这些方程通常受 CPU 限制，系统大小适中，但也可能受内存限制。
我在问小二进制大小是否应该成为高效代码的设计标准，或者我是否总是可以优先考虑显式代码（最终重复可以作为函数实现的代码块）和编译器优化，例如循环展开等。
我知道分析技术以及如何将它们应用于特定问题，但我想知道可以在多大程度上做出一般性陈述。
CPU 有缓存。
与 CPU 速度相比，对系统内存的访问速度较慢。这就是 CPU 具有缓存（由超快内存制成）的原因。
每个级别的 CPU 缓存都有不同的大小和速度。
因此，为了达到尽可能大的速度，避免在最低级别（不幸的是，这也是最小的缓存）刷新缓存是至关重要的。
两者都code将data强制刷新缓存。所以大小在这两种情况下都很重要。
例如：当Code 您jump或call. 当您在 a加载 a 时，Data 可能会产生缓存未命中。variableremote address
还有其他一些问题alignment可能会极大地影响速度，但没有什么比 CPU 缓存未命中更昂贵（重新加载 CPU 缓存涉及 CPU 内核同步，这不是一件容易的事：它可能需要大约 250 个 CPU 周期！）。
在不涉及特定于平台的细节的情况下，这就是可以说的。
结论：保持简单。而且小就是美。
CPU 只执行代码的一部分，所以它是代码的内容，以及你在其中移动多少，决定了速度。
如果你有 10Mb 的代码，并且前 9Mb 只在启动时执行一次，那么这 9Mb 是慢还是 90Mb 或 90kb 都没有关系。如果 CPU 将 99.99% 的时间花在一些小而紧凑的循环中进行一些非常有效的计算，那么它会很快，如果它必须一次又一次地运行 100,000 行代码，它可能会慢得多。
优化是要查看 CPU 大部分时间花在哪里，并使代码在获得答案所需的 CPU 周期数上尽可能高效。有时这可能意味着在其外部添加大量额外的“准备”代码，以使主要部分的工作更容易/更快。
在某些系统中，二进制大小是主要关注点（EG 嵌入式设备），但在其他系统中，它几乎完全无关紧要。
另见： http: //www.codeproject.com/Articles/6154/Writing-Efficient-C-and-C-Code-Optimization