這西科CD下面的漫畫表明程式碼需要大量時間來編譯（也許沒有足夠的時間來上演一場劍戰，但你明白了）。然而，使用我編寫的簡單 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 的唯一機器陷入了困境。我因為在終端機上閱讀平裝本而被叫去，在等待編譯完成的同時，我試著不睡著。