# 모든 .cpp 파일을 단일 컴파일 단위에 포함 하시겠습니까?
최근에 일반적인 디버그 및 릴리스 구성을 사용하는 일부 Visual Studio C ++ 프로젝트와 함께 작업하게되었지만 이전에 본 적이없는 '모두 릴리스'및 '모두 디버그'도 작업했습니다.
프로젝트 작성자는 다른 모든 .cpp 파일을 # 포함하는 단일 ALL.cpp를 가지고 있습니다. * All 구성은이 하나의 ALL.cpp 파일을 빌드합니다. 물론 일반 구성에서 제외되며 일반 구성은 ALL.cpp를 빌드하지 않습니다.
이것이 일반적인 관행인지 궁금했습니다. 어떤 이점이 있습니까? (첫 번째 반응은 냄새가 나쁘다는 것입니다.)
이와 관련하여 어떤 종류의 함정이 발생할 가능성이 있습니까? 내가 생각할 수있는 하나는 .cpps에 익명 네임 스페이스가있는 경우 더 이상 해당 cpp에 대해 '비공개'가 아니지만 다른 cpp에서도 볼 수 있다는 것입니다.
모든 프로젝트는 DLL을 빌드하므로 익명의 네임 스페이스에 데이터를 저장하는 것은 좋은 생각이 아닙니다. 하지만 기능은 괜찮을까요?
건배.
일부 (및 Google 가능)에서는 "Unity 빌드"라고합니다. 그것은 미친 듯이 빠르게 연결되고 합리적으로 빠르게 컴파일됩니다. 중앙 서버의 릴리스 빌드와 같이 반복 할 필요가없는 빌드에 적합하지만 반드시 증분 빌드를위한 것은 아닙니다.
그리고 유지해야 할 PITA입니다.
편집 : 여기에 더 많은 정보를위한 첫 번째 구글 링크가 있습니다 : http://buffered.io/posts/the-magic-of-unity-builds/
속도를 높이는 것은 컴파일러가 모든 .cpp 파일에 대해 수행하는 대신 모든 것을 한 번 읽고 컴파일 한 다음 링크하면된다는 것입니다.
Bruce Dawson은 자신의 블로그 ( http://randomascii.wordpress.com/2014/03/22/make-vc-compiles-fast-through-parallel-compilation/) 에서 이에 대해 훨씬 더 잘 작성했습니다.
Unity는 세 가지 주요 이유로 향상된 빌드 속도를 빌드합니다. 첫 번째 이유는 모든 공유 헤더 파일을 한 번만 구문 분석하면되기 때문입니다. 많은 C ++ 프로젝트에는 대부분 또는 모든 CPP 파일에 포함 된 많은 헤더 파일이 있으며 이들의 중복 구문 분석은 특히 짧은 소스 파일이 많은 경우 컴파일의 주요 비용입니다. 미리 컴파일 된 헤더 파일은이 비용에 도움이 될 수 있지만 일반적으로 미리 컴파일되지 않은 많은 헤더 파일이 있습니다.
Unity 빌드가 빌드 속도를 향상시키는 다음 주된 이유는 컴파일러가 더 적은 횟수로 호출되기 때문입니다. 컴파일러 호출에는 약간의 시작 비용이 있습니다.
마지막으로 중복 헤더 구문 분석의 감소는 인라인 함수에 대한 중복 코드 생성의 감소를 의미하므로 개체 파일의 전체 크기가 작아 져 링크 속도가 빨라집니다.
Unity 빌드는 더 나은 코드 생성을 제공 할 수도 있습니다.
Unity 빌드는 디스크 I / O 감소로 인해 더 빠르지 않습니다 . 저는 xperf로 많은 빌드를 프로파일 링했으며 제가 무슨 말을하는지 알고 있습니다. 메모리가 충분한 경우 OS 디스크 캐시는 중복 I / O를 방지합니다. 후속 헤더 읽기는 OS 디스크 캐시에서 발생합니다. 메모리가 충분하지 않은 경우 Unity 빌드는 컴파일러의 메모리 공간이 사용 가능한 메모리를 초과하여 페이지 아웃되도록하여 빌드 시간을 더욱 악화시킬 수 있습니다.
디스크 I / O는 비용이 많이 들기 때문에 모든 운영 체제에서 중복 디스크 I / O를 피하기 위해 데이터를 적극적으로 캐시합니다.
ALL.cpp가 전체 프로젝트를 단일 컴파일 단위에 넣어 컴파일러가 프로그램을 크기에 맞게 최적화하는 기능을 향상 시키려고 시도하고 있는지 궁금합니다.
일반적으로 일부 최적화는 중복 코드 제거 및 인라인과 같은 고유 한 컴파일 단위 내에서만 수행됩니다.
즉, 최근의 컴파일러 (Microsoft, Intel,하지만 GCC를 포함하지 않는다고 생각합니다)가 여러 컴파일 단위에서이 최적화를 수행 할 수 있다는 것을 기억하는 것 같으므로이 '트릭'이 필요하지 않은 것 같습니다.
즉, 실제로 차이가 있는지 확인하는 것이 궁금합니다.
나는 Bruce에 동의합니다. 내 경험으로 나는 많은 헤더 포함과 많은 .cpps가있는 내 .dll 프로젝트 중 하나에 대해 Unity 빌드를 구현해 보았습니다. VS2010의 전체 컴파일 시간을 줄이려고 (이미 증분 빌드 옵션을 모두 사용 했음) 컴파일 시간을 줄이는 대신 메모리가 부족하여 빌드가 컴파일을 완료 할 수도 없습니다.
그러나 추가하려면; Visual Studio에서 Multi-Processor Compilation 옵션을 활성화하면 컴파일 시간을 줄이는 데 큰 도움이됩니다. 다른 플랫폼 컴파일러에서 이러한 옵션을 사용할 수 있는지 확실하지 않습니다.
Bruce Dawson의 탁월한 답변 외에도 다음 링크는 Unity 빌드의 장단점에 대한 더 많은 통찰력을 제공합니다-https: //github.com/onqtam/ucm#unity-builds
우리는 MacOS와 Windows를위한 다중 플랫폼 프로젝트를 가지고 있습니다. 많은 대형 템플릿과 포함 할 헤더가 많습니다. 미리 컴파일 된 헤더를 사용하여 Visual Studio 2017 msvc로 빌드 시간을 절반으로 줄였습니다. MacOS의 경우 빌드 시간을 줄이기 위해 며칠 동안 노력했지만 미리 컴파일 된 헤더는 빌드 시간을 85 %로 줄였습니다. 단일 .cpp 파일을 사용하는 것이 돌파구였습니다. 우리는 단순히 스크립트로이 ALL.cpp를 생성합니다. ALL.cpp에는 프로젝트의 모든 .cpp 파일이 포함 된 목록이 있습니다. XCode 9.0을 사용하여 빌드 시간을 30 %로 줄였습니다. 유일한 단점은 .cpp-Files의 모든 비공개 unamed 컴파일 단위 네임 스페이스에 이름을 지정해야한다는 것입니다. 그렇지 않으면 로컬 이름이 충돌합니다.
참고 URL : https://stackoverflow.com/questions/543697/include-all-cpp-files-into-a-single-compilation-unit
'IT박스' 카테고리의 다른 글
| ASP.NET MVC 3 및 Stackoverflow의 Markdown을 사용하는 방법 (0) | 2020.11.05 |
|---|---|
| gcc에서 '-l'옵션의 순서가 중요한 이유는 무엇입니까? (0) | 2020.11.05 |
| 데이터 바인딩 유형을 안전하게 만들고 리팩토링을 지원하는 방법 (0) | 2020.11.05 |
| C # 기본 키워드의 F #에 해당하는 것은 무엇입니까? (0) | 2020.11.05 |
| Google 크롬 백그라운드 스크립트를 디버그하는 방법은 무엇입니까? (0) | 2020.11.05 |