[我经常看到程序员，特别是在StackOverflow上，他们指出了各自程序的编译时间，并且有时这样做的目的是缩短这些相应的周期，即使结果只是微妙的。
当然，我可以理解的是，当程序员处于任何程序的开发过程中以及创建，测试和编辑源代码的来回节奏时，要保持这些进程之间的时间间隔较短很重要，但我只是不明白，如果编译时间只有几毫秒，这为什么会是一个大问题？
即使是几秒钟，为什么要这样呢？那时我们可以从编码或其他任何事情中放松一点。
我们只是太急了吗？
或者在编译时我是否还缺少某种伪装的迹象？
为什么编译时间的持续时间很重要？它表明一些吗？
非常感谢您的回答和评论。
我只是不明白，如果编译时间只有几毫秒，这为什么会有这么大的问题？
因为这不是“几毫秒”的问题。只有小型和/或玩具应用程序需要很短的时间来编译。
[当人们抱怨C ++编译时间时，他们抱怨的是几分钟或小时的时间尺度（对于大型项目来说，长达一整天的完整重建并非闻所未闻）。大规模C ++开发的编译时间是如此之大。在程序中触摸错误的标题有时会调用一个多小时的编译。
程序员的工作是编程。这意味着要编写代码，还要执行和测试它。编译时间是指停滞时间，在这段时间中，这实际上没有发生。
那时我们可以从编码或其他任何事情上放松一点。
[有一个心理概念“ flow",，您的思维顶空紧紧地专注于您正在执行的任务。从计算机的角度来看，您可以将流视为处于指令和数据缓存已全部包含的状态进行复杂计算所需的代码和信息。因此，一切都在尽可能高效地移动。
“松弛”来自流，就像转储缓存。即使只是短暂的休息。要恢复工作状态，现在必须将所有内容重新加载到内存中。是的，这并不需要花费大量时间，但是它的效率远远低于没有该缓存转储的情况。
大于一分钟左右的时间不仅仅只是转储缓存，还包括整个虚拟内存。因此，现在您尝试做的只是页面错误，需要访问硬盘。同样，您可以完成工作，但是它发生的速度比必要的慢得多。
所以即使程序员可以在完成其他任务上取得进步，他们的工作效率也没有达到应有的水平。
C程序可以快速编译，或者可以快速编译，但要以生成的可执行文件的运行时性能为代价。
关键概念是compiler optimization。这是一门艺术，作为一个问题，它是无法解决的（因为Rice's theorem）。
著名的数学问题可以重新表述为编译器优化问题。看看Julia Robinson起作用了。