그만큼XKCD아래 만화는 코드를 컴파일하는 데 상당한 시간이 걸린다는 것을 암시합니다(검투를 벌이는 데는 시간이 충분하지 않을 수도 있지만 아이디어는 얻을 수 있습니다). 하지만 제가 작업한 간단한 Java 코드를 사용하면 BlueJ에서 1,000줄 정도를 컴파일하는 데 2초도 채 걸리지 않으며 Eclipse와 같은 다른 IDE에서는 어느 정도 즉시 컴파일되는 것처럼 보입니다.
따라서 어떤 상황(언어, 코드 복잡성 등)에서 코드 조각을 컴파일하는 데 실제로 오랜 시간(예: 1분 이상)이 걸리는지, 아니면 이 만화가 단순히 창의적 자유를 누리고 있는지(xkcd와는 다른 것으로 보임)입니다.
답변1
여기에는 많은 요인이 있지만 크기가 가장 큰 요인입니다. 대부분의 최신 빌드 시스템은 코드를 변경할 때 부분 컴파일을 수행하여 변경된 부분만 빌드하려고 시도합니다. 그러나 일부 도구는 이를 수행할 수 없습니다.
수백 개의 프로젝트에 걸쳐 수백만 줄의 .NET 코드를 컴파일하면 컴파일 시간이 상당히 길어지기 시작합니다. 네이티브 C/C++ 세계에서 흔히 수행되는 것처럼 대규모 라이브러리를 컴파일하는 동시에 자신만의 소스 코드도 컴파일하는 경우 컴파일 시간도 늘어나게 됩니다.
특히 C와 C++에서는 헤더를 구문 분석하는 데 소요되는 시간이 상당합니다. 수천 개의 헤더를 반복해서 읽는 것은 매우 막대한 I/O 바운드 프로세스입니다. 이것이 미리 컴파일된 헤더 기술이 만들어진 이유 중 하나입니다. 물론 SSD를 사용하면 속도도 크게 향상됩니다.
편집: 빌드에 특수 코드 생성기나 DSL 컴파일러가 포함되는 경우가 많다는 사실을 언급하는 것을 잊었습니다. 이러한 도구는 널리 사용되는 도구만큼 고도로 최적화되지 않은 맞춤형 사내 프로젝트인 경우가 많으므로 많이 사용하면 병목 현상이 발생할 수 있습니다.
답변2
오늘날의 기술로는 컴파일하는 데 1분이라도 걸리려면 꽤 큰 코드 기반이 필요합니다. 하지만 공룡(메인프레임과 대형 미니 컴퓨터 - PDP 11/70, 코어 메모리 64K가 떠오른다)이 지구를 떠돌던 시절(70년대 중반)에는 소프트웨어팀의 유일한 컴퓨터에 연결된 단말기조차 지금보다 컸다. 데스크탑 PC. 9600 보드 연결이 있었다면 당신은 선택된 소수 중 하나였습니다. 우리 대부분은 2400으로 업그레이드된 것에 감사했습니다! 기계는 연결된 사용자들 사이에서 시간을 공유하고 라운드 로빈 방식으로 작업을 시간 분할했습니다.
마감일이 다가오고 모든 사람이 대상 시스템의 일부를 컴파일하려고 하면 터미널 통신 응답 시간에도 문제가 발생합니다. 심각한 경우에는 CPU가 실제로 작업을 처리하는 동안 디스크에서 작업을 교환하는 데 많은 시간을 소비했습니다. 이러한 상황에서는 몇 분 정도의 컴파일 시간이 드물지 않았습니다.
마감일이 다가온 어느 날 밤 오전 3시 30분쯤에 그 만화와 비슷한(더 나쁜!) 대화를 했던 기억이 납니다. 부서는 3교대 근무를 하고 있었습니다(교대 차등? 그거 망쳐요!). 프로젝트가 너무 인간적이어서 25명의 SWE를 위한 유일한 기계가 너무 수렁에 빠졌기 때문입니다. 편집이 완료되기를 기다리는 동안 잠들지 않으려고 터미널에서 문고본을 읽었다는 이유로 호출을 받았습니다.