g++编译时间是否取决于数组大小？

Question

我有一份C++代码，其中包含3个数组声明。 float A[NUM]; float B[NUM]; float C[NUM]; 当我使用NUM=512编译时，编译速度很快。 time g++ -DNUM=512 trials trials.cpp -lm 0.16s 用户 0.04s 系统 94% CPU 0.219 总共

然而，当我使用NUM=167772160编译时，需要更长的时间。 time g++ -DNUM=167772160 trials trials.cpp -lm 7.90s 用户 0.69s 系统 99% CPU 8.604 总共

虽然编译后的目标文件大小相同，但我多年没有用过C ++。我很好奇为什么在编译时会有时间差异。

- mutelogan

---

这些数组是静态数据吗？ - David Rodríguez - dribeas

它们是全局声明。 - mutelogan

谁知道g++尝试做什么优化。也许它分配这样一个数组来检查并警告无效的内存访问。尝试使用-O0再次运行基准测试（可能要多次运行），并将编译和链接分开进行。 - j13r

这可能与此错误相关或其中一个已提到的错误有关：http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923。您使用的gcc版本是什么？ - j13r

按照C和C ++标准，全局变量/静态变量需要初始化为0。现在，GCC通常将这些数据放在.bss部分中。您可以执行以下操作：1）检查两个值的.bss部分；2）查看汇编器输出。尝试向编译器传递“ -fno-zero-initialized-in-bss”选项，查看是否有任何区别。 - dirkgently

可能是静态分配程序编译时间长的重复问题。 - Praetorian

Answer 1

这是一个相当著名的难题。在某个地方，数组的实际内存将被分配。

参见： 链接器性能与交换空间有关吗？

看起来 ld 实际上正在尝试匿名映射该数组的整个静态内存空间（或可能是整个程序，很难确定，因为整个程序非常小，可能可以全部放在那多出来的 4096 中）。

还相关的是：

• 具有静态分配的程序编译时间长
• GCC 的奇怪行为
• gc 中缺失优化：http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131

- sehe

Answer 2

你的数组是在局部声明还是全局声明的？ 如果是全局声明，因为链接器应该在.data节中分配内存，这可能需要很长时间。 然而，如果你在局部声明它，因为内存是在运行时分配的，而不是链接时。这将成为链接器的问题，而不是编译器的分析器或优化器引起的问题。

- Ling Kun