优化：更快的编译答案

【问题标题】：Optimization: Faster compilation优化：更快的编译
【发布时间】：2018-04-06 13:26:43
【问题描述】：

如果交给智能编译管理器，将程序分成头文件和源文件可能会有助于加快编译速度，而这正是我正在做的工作。

理论工作：为每个源文件创建一个线程并一次将每个源文件编译成目标文件。然后将这些目标文件链接在一起。它仍然需要等待源文件最慢。这应该不是问题，因为可以实现一个简单的n != nSources 计数器，它会随着每个生成的 .o 递增。

我认为默认情况下的 GCC 不会这样做。当它调用汇编程序时它应该一个一个地解析文件。

这是一种有效的方法吗？如何进一步优化编译时间？

【问题讨论】：

【解决方案1】：

所有现代（如 2000 年后）品牌都提供此功能。 GNU make 和各种风格的 BSD make 都将使用 -j 标志在单独的线程中编译源文件。当然，它只需要你有一个makefile。 Ninja 默认也这样做。它大大加快了编译速度。

【讨论】：

看得出你喜欢做哈哈。我制作程序来自动化一切以及优化。这就是我的编程风格。我为什么要费心学习制作和使用其他文件..
既然可以用汇编语言编写代码，为什么还要学习 C？当你可以很好地用十六进制编写程序时，为什么还要学习汇编程序？
你认为使用 make 更容易，我不这么认为。也更容易不是>更好。不是重用的忠实粉丝。更喜欢更大的控制权并且没有版权问题。
你根本没有解决我的观点。但即使是你的不合逻辑也是愚蠢的，并且有几个原因。为什么更容易而不是更好？尤其是在这种情况下，您可以更好地控制输出？为什么你不喜欢重复使用东西？此外，BSD 会在什么领域出现哪怕是最轻微的版权问题？此外，如果你不喜欢 make，你为什么打算制作一个做同样事情的程序？
我很担心你一直想把某事称为“愚蠢”的冲动。