这西科光盘下面的漫画表明代码需要花费大量时间来编译（可能没有足够的时间来进行一场剑斗，但你明白我的意思）。但是，对于我曾经处理过的简单 Java 代码，在 BlueJ 中编译 1,000 行左右的代码只需不到 2 秒，而其他 IDE（例如 Eclipse）似乎在某种程度上可以即时编译。
那么在什么情况下（语言、代码复杂性等）一段代码实际上需要很长时间（比如说，> 1 分钟）来编译，或者这个漫画只是在发挥创作自由（这似乎与 xkcd 不同）。
答案1
造成这种情况的因素有很多，但大小是其中最重要的一个。大多数现代构建系统都会在您更改代码时尝试执行部分编译，以便只构建更改的部分。但是，有些工具无法做到这一点。
当编译分布在数百个项目中的数百万行 .NET 代码时，编译时间开始变得相当长。当编译大型库并编译您自己的源代码时（就像在原生 C/C++ 世界中经常做的那样），您的编译时间也会增加。
尤其是对于 C 和 C++，解析头文件所花费的时间相当长。反复读取数千个头文件是一个非常繁重的 I/O 绑定过程。这就是创建预编译头文件技术的原因之一。当然，SSD 也可以大大加快这一速度。
编辑：我忘了说，构建通常包括专门的代码生成器或 DSL 编译器。这些工具通常是内部定制的项目，没有像广泛使用的工具那样经过高度优化，因此如果使用频繁，它们可能会成为瓶颈。
答案2
使用当今的技术，编译一个相当大的代码库甚至需要一分钟的时间。但是当恐龙（大型机和大型微型计算机 - PDP 11/70，64K 核心内存浮现在脑海中）在地球上漫游时（70 年代中期），即使是连接到软件团队的唯一计算机的终端也比今天的台式电脑大。如果您拥有 9600 波特的连接，那么您就是少数被选中的人之一 - 我们大多数人都很高兴升级到 2400！机器在连接的用户之间分时共享，以循环方式对作业进行时间分片。
当截止日期临近，每个人都在努力编译目标系统的一部分时，甚至终端通信响应时间也会受到影响。在严重的情况下，CPU 花费在从磁盘交换作业上的时间与实际处理作业的时间一样多。在这种情况下，编译时间长达数分钟的情况并不罕见。
我记得有一次与那幅漫画类似的（更糟糕！）对话，那是一天晚上 3:30 左右，临近最后期限。由于项目管理非常糟糕，部门实行 3 班倒（班次差异？去他的！），25 名 SWE 的唯一一台机器陷入了困境。我在等待汇编完成时，因为在终端上阅读一本平装书而被叫出去，我努力不睡着。