gcc - 静态分配的程序编译时间长

Question

如果有人能告诉我为什么编译这个程序，我将不胜感激:

double data[123456789];  
int main() {}

比编译这个时间长 10 倍:

int main() {
    double* data=new double[123456789];
}

当两者都编译时:

$ g++ -O0

并且可执行文件的大小几乎相同。

我在 Ubuntu 10.04 上使用 gcc 4.4.3。

谢谢你。

Answer 1

动态分配

你的第二个程序在运行时分配内存；从编译器的角度来看，编译以下任何内容没有真正的区别:

double *data = new double[123456789];
double *data = malloc(123456789);
double data  = sqrt(123456789);

它们都做不同的事情，但编译器需要做的就是生成对带有固定参数的外部函数的调用。如果您使用 g++ -S 生成程序集，您可以看到这一点:

.text
main:
    subq    $8, %rsp          /* Allocate stack space. */
    movl    $987654312, %edi  /* Load value "123456789 * 8" as argument. */
    call    _Znam             /* Call the allocation function. */
    xorl    %eax, %eax        /* Return 0. */
    addq    $8, %rsp          /* Deallocate stack space. */
    ret

这对于任何编译器生成和任何链接器链接都很简单。

静态分配

不过，正如您所注意到的，您的第一个程序有点诡异。如果我们查看它的程序集，我们会看到一些不同的事情发生:

.text
main:
    xorl    %eax, %eax        /* Return 0. */
    ret

.bss
data:
    .zero   987654312         /* Reserve "123456789 * 8" bytes of space. */

生成的程序集要求在程序首次启动时保留 123456789 * sizeof(double) 字节的空间。当它被组装并随后链接时(在幕后发生的是你只是运行 g++ foo.c )，链接器 ld 实际上会在内存中分配所有这些保留空间。这就是时间的去向。如果在 top 运行时运行 g++，您会看到 ld 占用了大量系统内存。

减小的可执行文件大小

一个合理的问题可能是“如果内存在链接时被保留，为什么我的可执行文件最终不会很大？”。答案隐藏在程序集中的 .bss 标记中。这告诉链接器它下面定义的数据不应该存储在最终的可执行文件中，而是在运行时分配为零。

这给我们留下了以下一系列步骤:

汇编器告诉链接器它需要创建一段 1GB 长的内存。

链接器继续分配此内存，准备将其放入最终可执行文件中。

链接器意识到这块内存在 .bss 部分，并被标记为 NOBITS ，这意味着数据只是 0，不需要物理放入最终的可执行文件中。它避免写出 1GB 的数据，而只是将分配的内存扔掉。

链接器将编译后的代码写入最终的 ELF 文件，生成一个小的可执行文件。

更智能的链接器可能能够避免上面的第 2 步和第 3 步，从而使您的编译时间更快。实际上，像您这样的场景在实践中出现的频率并不高，因此值得进行这样的优化。

动态与静态分配

如果您正在尝试确定在您的程序中实际使用上述哪一个(动态分配还是静态分配)，这里有一些想法:

链接器需要使用与最终程序一样多的内存(加上一点)。如果要静态分配 4GB 的 RAM，则链接器需要 4GB 的 RAM。这并不隐含在链接器的工作方式中，而似乎只是它们的实现方式。

分配大量内存时，动态分配可以让您更好地处理错误(在屏幕上显示一条用户友好的消息，说明您没有足够的内存，而不是仅仅无法加载带有来自操作系统的消息的可执行文件前往用户)；

动态分配内存允许您根据实际需要选择分配多少内存。 (如果data是缓存，用户可以选择缓存大小，如果是存储中间结果，可以根据问题大小等)

动态分配内存允许您稍后释放它，如果您的程序需要在完成内存后继续执行并执行更多工作。

最后，如果以上几点都无关紧要，并且您可以处理更长的编译时间，则可能没有太大关系。静态分配内存可以简单得多，并且通常是少量内存或一次性应用程序的正确方法。