DerXKCDDer Comic unten lässt vermuten, dass das Kompilieren von Code eine beträchtliche Zeit in Anspruch nimmt (vielleicht nicht genug Zeit, um einen Schwertkampf zu veranstalten, aber Sie verstehen, was ich meine). Bei den einfachen Java-Codes, an denen ich gearbeitet habe, dauert es jedoch weniger als 2 Sekunden, um etwa 1.000 Zeilen in BlueJ zu kompilieren, und andere IDEs wie Eclipse scheinen bis zu einem gewissen Grad im laufenden Betrieb zu kompilieren.
Unter welchen Umständen (Sprache, Codekomplexität usw.) würde das Kompilieren eines Codestücks tatsächlich lange dauern (sagen wir > 1 Minute), oder nimmt sich dieser Comic einfach nur kreative Freiheiten heraus (was xkcd unähnlich zu sein scheint)?
Antwort1
Dazu tragen viele Faktoren bei, aber die Größe ist ein wichtiger. Die meisten modernen Build-Systeme versuchen, bei Codeänderungen eine Teilkompilierung durchzuführen, sodass nur die geänderten Teile erstellt werden. Einige Tools sind dazu jedoch nicht in der Lage.
Wenn Sie Millionen von Zeilen .NET-Code kompilieren, die über Hunderte von Projekten verteilt sind, wird die Kompilierungszeit ziemlich lang. Wenn Sie große Bibliotheken kompilieren und gleichzeitig Ihren eigenen Quellcode kompilieren, wie dies häufig in der nativen C/C++-Welt der Fall ist, erhöhen sich auch Ihre Kompilierungszeiten.
Besonders bei C und C++ ist der Zeitaufwand für das Parsen von Headern beträchtlich. Das wiederholte Lesen von Tausenden von Headern ist ein sehr aufwändiger E/A-Prozess. Dies ist einer der Gründe, warum die Technik der vorkompilierten Header entwickelt wurde. Natürlich beschleunigt eine SSD auch diesen Vorgang erheblich.
Edit: Ich habe vergessen zu erwähnen, dass Builds oft spezielle Codegeneratoren oder DSL-Compiler enthalten. Diese Tools sind oft maßgeschneiderte Inhouse-Projekte, die nicht so optimiert sind wie weit verbreitete Tools, sodass sie bei intensiver Nutzung zu einem Engpass werden können.
Antwort2
Mit der heutigen Technologie würde das Kompilieren einer ziemlich großen Codebasis auch nur eine Minute dauern. Aber damals, als Dinosaurier (Großrechner und große Minicomputer - man denke nur an PDP 11/70, 64 KB Arbeitsspeicher) die Erde bevölkerten (Mitte der 70er Jahre), war selbst ein Terminal, das an den einzigen Computer eines Softwareteams angeschlossen war, größer als die heutigen Desktop-PCs. Wenn Sie eine 9600-Baud-Verbindung hatten, gehörten Sie zu den Auserwählten - die meisten von uns waren dankbar, auf 2400 aufgerüstet zu werden! Die Maschine wurde unter den angeschlossenen Benutzern zeitgeteilt, wobei die Jobs im Round-Robin-Verfahren zeitgeteilt wurden.
Wenn eine Frist näher rückte und jeder versuchte, seinen Teil des Zielsystems zu kompilieren, litten sogar die Reaktionszeiten der Terminalkommunikation darunter. In schweren Fällen verbrachte die CPU genauso viel Zeit damit, Jobs von der Festplatte zu übertragen, wie damit, sie tatsächlich zu verarbeiten. In solchen Situationen waren Kompilierzeiten im Bereich von mehreren Minuten keine Seltenheit.
Ich erinnere mich an ein ähnliches (schlimmeres!) Gespräch wie in diesem Cartoon, eines Nachts um 3:30 Uhr, als eine Deadline näher rückte. Die Abteilung arbeitete in 3 Schichten (Schichtdifferenzial? Scheiß drauf!), weil das Projekt so schlecht manövriert war, die einzige Maschine für 25 SWEs war so überlastet. Ich wurde gerufen, weil ich an meinem Terminal ein Taschenbuch las und versuchte, nicht einzuschlafen, während ich darauf wartete, dass eine Kompilierung abgeschlossen wurde.