긴 컴파일은 과거의 일입니까?

컴파일에 걸리는 시간에 대한 수많은 전쟁 이야기가 있습니다. xkcd 조차도 언급했습니다.

이제는 오랫동안 프로그래밍하지 않았으며 대부분 Java와 Python에 노출되었습니다 (Python은 컴파일 된 언어가 아닌 해석 된 언어입니다). 컴파일하는 데 시간이 오래 걸리는 프로젝트를 보지 못했을 수도 있지만 적절한 크기의 앱조차도 즉각적으로 (일반적으로 IDE에서 백그라운드에서 처리) 또는 30을 넘지 않는 것으로 나타났습니다. 매우 큰 프로젝트의 경우 몇 초 정도 걸립니다. 만화가 이루어지는 비즈니스 환경에서도 컴파일하는 데 오래 걸리지 않았습니다.

컴파일 시간이 긴 프로젝트에 노출되지 않았습니까? 더 이상 현대에 일어나지 않는 과거의 유물입니까? 컴파일에 왜 그렇게 오래 걸립니까?

특히 C, C ++ 또는 Scala와 같은 언어로 작성된 대규모 프로젝트의 경우 컴파일에 시간이 걸릴 수 있습니다. 백그라운드에서 파트를 컴파일하면 컴파일 시간이 단축 될 수 있지만 때로는 새로운 컴파일을 수행해야합니다. 컴파일 시간이 길어질 수있는 요소는 다음과 같습니다.

• 분명히 큰 코드 크기. 대규모 프로젝트에는 수십만 줄의 코드가 있습니다.

• C의 #include전 처리기 지시문은 동일한 코드가 수백 번 효과적으로 컴파일되도록합니다. 매크로 시스템은 텍스트 수준에서 작동하므로 비슷한 문제가 있습니다. 전처리 기는 실제로 컴파일러에 전달되는 코드 크기를 크게 증가시킵니다. 전처리 후 파일을 보면 (예 :을 통해 gcc -E) 눈을 뜨어야합니다.

• C ++의 템플릿은 Turing complete이므로 이론적으로 컴파일 타임에 임의의 계산을 수행 할 수 있습니다. 아무도 실제로 그렇게하고 싶지는 않지만 많은 간단한 경우조차도 템플릿을 전문화하는 데 많은 시간을 소비합니다.

• 스칼라는 상당히 젊은 언어이며 컴파일러는 끔찍하게 최적화되지 않았습니다. 현재 컴파일러는 매우 많은 수의 컴파일 패스를 사용합니다 (C는 두 개의 컴파일 패스 만 요구하도록 설계되었습니다). 유형 검사는 이러한 단계 중 하나이며 언어에 의해 특징 지어진 복잡한 유형 시스템으로 인해 시간이 걸릴 수 있습니다.

컴파일 만이 시간이 걸리는 것은 아닙니다. 프로젝트가 컴파일 된 후 테스트 스위트를 실행해야합니다. 이 작업에 소요되는 시간은 몇 초에서 몇 시간까지입니다 (테스트가 잘못 작성된 경우).

결코 과거의 유물이 아닙니다. 내가 작업하는 프로젝트 중 하나는 처음부터 새로 빌드하려면 45 분이 걸립니다. 자체 코드 외에도 외부 리포지토리의 여러 대형 C 및 C ++ 라이브러리에서 소스를 가져와 빌드해야합니다. C 및 C ++ 코드를 컴파일하고 연결하는 것은 계산 비용이 많이 듭니다. 알다시피, 파이썬은 일반적으로 해석 언어로 구현되며 Java는 일반적으로 JIT (Just in Time) 컴파일러를 사용하므로 프로젝트에서 선행 컴파일을 건너 뛰고 비용을 모두 연결합니다. 지불하는 가격은 시작 시간이 길고 (파이썬의 경우) 실행 속도가 느립니다.

빌드 시간이 길어지면 Jenkins 또는 TeamCity 와 같은 지속적인 통합 시스템을 활용하는 것이 더 중요합니다 . 이를 통해 개별 개발자는 변경 사항이 빌드를 손상시키지 않는지 테스트하면서 동시에 처음부터 건물의 고통을 피할 수 있습니다.

대규모 프로젝트에는 시간이 오래 걸릴 수 있습니다. 충분히 큰 프로젝트의 경우 한 시간 이상이 될 수 있습니다. 컴퓨터에있는 소스에서 컴파일해야하는 라이브러리가 몇 가지 있는데, 예를 들어 opencascade와 같습니다. 처음부터 다시 빌드해야하는 경우 Linux 커널 자체도 꽤 오랜 시간이 걸립니다.

그러나 훨씬 더 오래 걸릴 수있는 다른 컴파일과 유사한 프로세스가 있습니다. 디지털 회로 설계 (ASIC 또는 FPGA 용)에는 장소 및 경로 단계가 필요합니다. 위치 및 경로 단계는 개별 논리 게이트, 플립 플롭, 레지스터, RAM 및 기타 구성 요소의 배치가 상호 연결 배선을위한 라우팅과 함께 결정되는 위치입니다. 이 소프트웨어는 타이밍 모델을 사용하여 가능한 배치에 대한 게이트 및 라우팅 지연을 결정하고이를 타이밍 제약 조건이 제공하는 한계와 비교 한 다음 배치 위치 및 와이어 경로를 조정하여 타이밍 요구 사항을 충족시킵니다. 때로는 소프트웨어가 타이밍을 맞추기 위해 게이트 크기를 조정하고 버퍼를 추가해야 할 수도 있습니다. 이 단계는 매우 계산 집약적이며 완료하는 데 몇 시간 또는 며칠이 걸릴 수 있습니다. 또한 실제로 병렬화가 잘되지 않습니다. 1 년 전쯤에 작업하고 있던 FPGA 설계가 있었는데 Virtex 6 HXT 565 FPGA의 약 절반 (565k LUT 중 ~ 300k)을 소비하고 장소와 경로를 완료하는 데 약 7 시간이 걸렸습니다. 코어 i7 CPU 디자인과 같은 제품을 실행하고 라우팅하는 데 시간이 얼마나 걸릴지 상상할 수 없습니다.

다른 답변은 이미 그렇습니다. 큰 프로젝트의 코드는 500k 이상을 의미하며 특히 처음부터 빌드 할 때 상당한 시간이 걸릴 수 있다고 언급했습니다.

추가적인 목표는 여러 프로젝트가 여러 대상 환경에 맞게 구축되어야한다는 것입니다. 해당 환경을 호스팅하는 머신을 사용할 수없는 경우 빌드 한 머신에서 직렬로 교차 컴파일하여 빌드를 수행해야합니다. 이는 상당한 빌드 시간으로 이어질 수 있습니다 . 내가 작업 한 한 프로젝트의 야간 빌드에는 10 시간이 걸렸습니다. 당신이 그것을 부러 뜨린 사람이라고 화가 생각합니다!

나는 당신이 시간 낭비에 대한 그런 변명으로 도망 치지 않을 것이라고 덧붙입니다. 전문가 는 그러한시기에 유용한 일 을 할 수 있도록 업무를 계획해야합니다 .

둘 다 조금 C ++ (및 C는 덜)은 느린 컴파일 시간, 특히 기간 하드웨어에서 악명 높았습니다. 밀레니엄 시대가되었을 무렵, 나는 매크로 셰 나니 건으로 인해 약 4 시간이 걸리는 프로젝트를 진행했습니다.

요즘에는 상황이 더 좋지만 30 초는 경험상 상당히 낮습니다. 특히 소스 제어, 단위 테스트 실행, 설치 프로그램 빌드 및 모든 곳에서 SAN으로 전송 된 모든 항목을 체크 아웃해야하는 공식 빌드에서 특히 그렇습니다.

프로젝트와 컴파일 환경에 따라 다릅니다. 나는 컴파일하는 데 몇 분이 걸리는 C ++ 프로젝트 (MSVS에서 여러 프로젝트로 설정)를 연구했습니다.

거대한 코드 및 데이터베이스 (Proctor 및 Gamble, Google 등)가있는 대기업 또는 매우 복잡한 하나 또는 두 개의 기본 제품 (예 : 과학적 시뮬레이션 및 렌더링)에 중점을 둔 소규모 회사 또는 신생 회사에서 근무하는 경우, 그런 다음 큰 프로젝트가 컴파일되기를 기다리는 것은 강력한 기계에서도 기대할 수있는 현실적인 일입니다. 이는 코드 개발 및 디버그 방법과 버전 관리를 통해 변경 사항을 업데이트하고 병합하는 빈도에 영향을 줄 수 있습니다.