C 程序可以快速编译，或者可以快速编译，但会牺牲生成的可执行文件的运行时性能。
编写一个可以快速编译为缓慢运行的 x86 可执行文件的 C 编译器是一个简单的练习。Fabrice Bellard 制作了TinyCC（少于 20k 行的 C 代码）。但在实践中，您希望您的 C 编译器（例如GCC）能够非常巧妙地编译。我关于Bismon的这份草稿报告给出了巧妙优化的例子。这就是为什么 GCC 是一千万行代码的怪物。
关键概念是编译器优化（循环展开、内联扩展、自动向量化、寄存器分配）。这是一门艺术，作为一个问题，它是无法解决的（因为莱斯定理）。阅读Dragon 书籍以了解编译器问题。
著名的数学问题可以重新表述为编译器优化问题。看看Julia Robinson做了什么。
C++14 的编译略有不同。它的标准 C++ 库定义了难以编译的容器，因为 C++ 中的模板扩展是图灵完备的。因此，一些 C++ 奇怪的程序很短，但编译可能需要不合理的时间。
还要注意标准 C++ 头文件非常大：#include
C++ 的未来（可能是 C++20）版本可能有modules。
而且您可以启用链接时间优化（使用 GCC，编译和链接gcc -O2 -flto），这基本上会编译您的代码两次，粗略地说。
一些大型 C 或 C++ 程序可能需要数小时的 CPU 才能构建。据传 Google 专有索引代码是由 8 亿多行 C++ 行编译而成的单个 ELF 可执行文件。Oracle 数据库产品传闻是 50 亿行 C++。
一些大型系统有很多行：例如，典型 Linux 发行版中的所有源代码大约有 200 亿行代码（其中一半是 C 或 C++）。
我已经 60 岁了，足以记得我一个人编写的 C 代码何时需要一个小时的编译时间。
使用元编程技术，您可以从几千行输入中获得大量“发出”的 C 代码。
认知科学告诉我们，软件开发人员会在几分钟甚至几秒钟内失去注意力（例如，在考虑错误时）。
在功能强大的桌面上编译整个Linux 内核 需要几分钟时间。从分布式源代码 tarball编译整个Qt工具包（在 C++ 中）或GCC 9的源代码需要几个小时。编译Firefox可能需要一天以上的时间。
如果编译时间只有几毫秒？
这从来没有发生在我身上，除了hello world程序。而我的桌面是运行 Debian/Unstable 的强大 AMD2970SX。即使是像refpersys这样的小程序（2019 年 12 月 19日的 6000 行 C++ ，git commit b1af17cb5e693efad0）也需要 3.2 秒才能构建（使用omake -j 10）
请教我如何在几毫秒内构建像 RefPerSys 这样的小程序。