是否有使用的编译器很少关注编译速度，而是在编译时间减慢的情况下寻求最大优化？
在我看来，一旦你接近最终版本，编译需要数小时/天与分钟/秒不会成为主要问题。 （如果你有足够的测试，它应该是安全的。）
编辑：我感兴趣的是包含优化传递的编译器，这些优化传递可能需要数小时甚至数天才能在适度的程序上运行（通过正常优化需要10分钟或更短时间，例如Linux内核，apache或GCC自）。
答案 0 :(得分：4)
实际上，是的。不是因为优化器很慢，而是因为你要求优化器做的事情是必要的，需要很长时间。例如，我使用LLVM来优化整个程序：已编译的源文件以及源文件使用的所有库。一切都作为中间代码链接并一起优化。此优化明显慢于链接单独优化的目标文件。但我不在乎，原因有两个：1，优化是在整个程序中完成的，值得等待（;-)和2，计算机一直变得更快。
答案 1 :(得分：2)
在某种程度上，它们“慢”，只是计算机速度如此之快，并且拥有如此丰富的内存，以至于你不像以前那样注意到......
::用g ++ ::
进行一些实验我为工作写了一个稍微蹩脚的代码（大约24k LOC在c ++中75个文件中大量使用ROOT库，但没有模板）
-O0：8.88秒-O4：13.60秒-Os：11.32秒嗯......并不是编译时间的很大一部分。也许它只是由文件访问时间占主导地位。也许我应该用mplayer或其他真正密集的东西来尝试。