の翻訳下の漫画は、コードのコンパイルにかなりの時間がかかることを示しています (剣闘をするには十分ではないかもしれませんが、その意味はわかります)。ただし、私が作業した単純な Java コードでは、BlueJ で 1,000 行程度をコンパイルするのに 2 秒もかかりません。また、Eclipse などの他の IDE でも、ある程度はオンザフライでコンパイルされるようです。
では、どのような状況 (言語、コードの複雑さなど) で、コードのコンパイルに実際に長い時間 (たとえば、1 分以上) がかかるのでしょうか。それとも、このコミックは単に創造的な自由を取っているだけなのでしょうか (xkcd とは似ても似つかない)。
答え1
これに影響する要因は多数ありますが、サイズは大きな要因の 1 つです。最近のビルド システムのほとんどは、コードを変更すると部分的なコンパイルを実行し、変更された部分のみがビルドされるようにします。ただし、一部のツールではこれが実行できません。
数百のプロジェクトにまたがる数百万行の .NET コードをコンパイルする場合、コンパイル時間は非常に長くなります。ネイティブ C/C++ の世界でよく行われるように、大規模なライブラリをコンパイルすると同時に独自のソース コードもコンパイルする場合も、コンパイル時間は長くなります。
特に C と C++ では、ヘッダーの解析にかなりの時間がかかります。何千ものヘッダーを何度も繰り返し読み取るのは、非常に負荷の高い I/O バウンド プロセスです。これが、プリコンパイル ヘッダー テクニックが開発された理由の 1 つです。もちろん、SSD を使用すると、この処理も大幅に高速化されます。
編集: ビルドには特殊なコード ジェネレーターや DSL コンパイラーが含まれることが多いことを忘れていました。これらのツールは、広く使用されているツールほど高度に最適化されていないカスタムメイドの社内プロジェクトであることが多いため、頻繁に使用するとボトルネックになる可能性があります。
答え2
今日の技術では、コンパイルに 1 分もかからないほどの大きなコード ベースが必要です。しかし、恐竜 (メインフレームや大型ミニ コンピュータ - PDP 11/70、64K のコア メモリを思い浮かべてください) が地球上を闊歩していた頃 (70 年代中頃) は、ソフトウェア チームの唯一のコンピュータに接続された端末でさえ、今日のデスクトップ PC よりも大きかったのです。9600 ボーで接続できる人は、選ばれた少数の 1 人でした。ほとんどの人は、2400 にアップグレードできてありがたかったです。マシンは接続されたユーザー間でタイム シェアされ、ジョブはラウンドロビン方式でタイム スライスされていました。
締め切りが迫り、全員がターゲット システムの自分の部分をコンパイルしようとしているときは、端末通信の応答時間にも影響が出ます。ひどい場合には、CPU はジョブを実際に処理するのと同じくらいの時間をディスクからジョブにスワップするのに費やします。このような状況では、コンパイル時間が数分単位になることも珍しくありません。
締め切りが迫っていたある夜、午前 3 時半ごろ、その漫画に似た (もっとひどい!) 会話があったのを覚えています。プロジェクトがひどく遅れていたため、部門は 3 交代制 (交代差? そんなのどうでもいい!) で、25 人の SWE 用の唯一のマシンがひどく行き詰まっていました。コンパイルが完了するのを待っている間、私は眠くならないように端末でペーパーバックを読んでいたところ、呼び出されました。