为什么编译时的持续时间很重要？答案

【问题标题】：Why is the Duration of the Compile-time crucial important?为什么编译时的持续时间很重要？
【发布时间】：2020-04-12 03:29:10
【问题描述】：

我经常看到程序员，尤其是 StackOverflow 上的程序员，他们指出他们各自程序的编译时间，并且有时打算减少这些相应的时间，即使结果只是微妙的。

当然，我可以理解，当程序员在任何程序的开发过程中，以及创建、测试和编辑源代码的来回节奏，并以此保持这些过程之间的时间间隔short 很重要，但我就是不明白，如果编译时间只有几毫秒，为什么会有这么大的问题？

即使只有几秒钟，那又是为什么呢？在那段时间，我们可以从编码或其他任何事情中放松一下。

我们是不是太不耐烦了？

或者我还有什么关于编译时变相指示的遗漏吗？

为什么编译时的持续时间很重要？是不是有点暗示？

【问题讨论】：

如果只有几毫秒，那么它可能并不重要。检查您听到这些内容的实例，并检查它们是否指的是小于 100 毫秒的总编译时间。
程序员不是在第一次尝试时就编写出完美和正确解决方案的机器。我们有一个编写程序、编译和测试的工作流程，然后重新编写，因为第一次（和第二次和..）尝试是错误的。如果我们必须等待编译部分，这会减慢整个工作流程。时间就是金钱。如果有人设法将编译时间优化到几毫秒，那么我们就可以继续测试我们的更改。如果我们需要等待几个小时才能完成该步骤，这会在开发过程中造成瓶颈。附言尝试在笔记本电脑上编译 libreoffice 或 clang。
"如果编译时间只有几毫秒" - 您是否尝试过构建真正的实时应用程序？可能需要几个小时。 C++ 的编译效率极低。
编译单个源文件可能需要不到一秒钟的时间，但构建整个系统可能需要更长的时间。我曾开发过需要小时才能构建的系统。
为什么编译时的持续时间很重要？当它打断你的工作能力时，它变得很重要。我的意思是，当您按下编译并且必须等待 5 分钟以上才能进行任何测试时，您最终会尝试优化该过程。我在这里谈论的是专业编程，而不是你只构建几次的代码。

标签： c++ c performance compilation compile-time

【解决方案1】：

如果编译时间只有几毫秒，我只是不明白为什么会有这么大的问题？

因为这不是“几毫秒”的问题。只有很小的和/或玩具应用程序才需要这么短的时间来编译。

当人们抱怨 C++ 编译时间时，他们抱怨的是几分钟或小时的时间尺度（对于大型项目来说，为期一天的完全重建并非闻所未闻）。大规模 C++ 开发的编译时间如此之长。在程序中触摸错误的标头有时会调用数小时的编译。

程序员的工作是编程。这意味着编写代码，还要执行和测试它。编译时间是没有真正发生的死时间。

在那段时间，我们只是可以从编码或其他任何事情中放松一下。

有一个“flow",”的心理学概念，在这种概念中，您的大脑空间紧紧地专注于您正在执行的任务。从计算机的角度来看，您可以将流程视为处于指令和数据缓存具有的状态进行复杂计算所需的所有代码和信息。所以一切都在尽可能高效地移动。

从流程中“放松”就像倾倒你的缓存。哪怕只是短暂的休息。为了重新开始你正在做的事情，你现在必须将所有这些东西重新加载到内存中。是的，这不会花费大量时间，但它的效率远低于没有缓存转储的情况。

超过一分钟左右的时间间隔不仅会转储缓存，还会转储整个虚拟内存。因此，现在您尝试做的一切都是页面错误，需要硬盘访问。同样，您可以完成工作，但它发生的速度比必要的慢得多。

因此，即使程序员可以在其他任务上取得进展，他们的工作效率也不会达到应有的水平。

【讨论】：

为了完成您的“系统”描述，您可以补充说，将流量页面保持在 80% 左右是好的比率，只是为了避免“过热”。另外 20% 是编译时间“放松”的地方。

【解决方案2】：

C 程序可以快速编译，或者可以快速编译，但会牺牲生成的可执行文件的运行时性能。

编写一个可以快速编译为慢速运行 x86 可执行文件的 C 编译器是一项简单的练习。 Fabrice Bellard 制作了TinyCC（少于 20k 行 C 代码）。但实际上，您希望您的 C 编译器（例如 GCC）能够非常巧妙地编译。我在Bismon 上的draft report 给出了巧妙优化的示例。这就是为什么 GCC 是一千万行代码的怪物。

关键概念是compiler optimization（loop unrolling、inline expansion、automatic vectorization、register allocation）。这是一门艺术，作为一个问题，它是无法解决的（因为Rice's theorem）。阅读Dragon book 了解编译器问题的介绍。

著名的数学问题可以重新表述为编译器优化问题。看看Julia Robinson 的作用。

C++14 的编译略有不同。它的标准 C++ 库定义了难以编译的容器，因为 C++ 中的模板扩展为 Turing complete。所以一些 C++ 怪异的程序很短，但编译时间却不合理。

还要注意标准 C++ 标头相当大：在我的 Linux GCC 9 上，一个简单的 #include <vector> 会扩展到近一万行。

C++ 的未来（可能是 C++20）版本可能有 modules。

您可以启用link time optimizations（使用 GCC，编译并链接与gcc -O2 -flto），这基本上编译您的代码两次，粗略地说。

一些大型 C 或 C++ 程序可能需要数小时的 CPU 才能构建。据传 Google 专有索引代码是由 8 亿多行 C++ 行编译而成的单个 ELF 可执行文件。 Oracle 数据库产品传闻是 50 亿行 C++。

一些大型系统有很多行：例如，典型 Linux 发行版中的所有源代码大约有 200 亿行代码（其中一半是 C 或 C++）。

我已经 60 岁了，足以记住我单独编写的 C 代码何时需要一个小时的编译时间。

使用元编程技术，您可以从几千行输入中获得大量“发出”的 C 代码。

认知科学告诉我们，软件开发人员会在几分钟甚至几秒钟内失去注意力（例如在考虑错误时）。

在功能强大的桌面上编译整个Linux kernel 需要几分钟时间。从分布式源代码 tarball 编译整个 Qt 工具包（在 C++ 中）或 GCC 9 的源代码需要几个小时。编译Firefox 可能需要一天以上的时间。

如果编译时间只有几毫秒？

除了hello world 程序之外，我从来没有遇到过这种情况。而我的桌面是运行 Debian/Unstable 的强大 AMD2970SX。即使是像refpersys 这样的小程序（2019 年 12 月 19 日^th 今天的 6000 行 C++，git commit b1af17cb5e693efad0）也需要 3.2 秒才能构建（使用 omake -j 10）

请教我如何在几毫秒内构建像 RefPerSys 这样的小程序。

【讨论】：