STAPL 프로젝트에서 일하고 있습니다.이 템플릿은 C ++ 라이브러리입니다. 가끔 컴파일 시간을 줄이기 위해 모든 기술을 다시 방문해야합니다. 여기에서는 우리가 사용하는 기술을 요약했습니다. 이러한 기술 중 일부는 이미 위에 나열되어 있습니다.
가장 시간이 많이 걸리는 섹션 찾기
심볼 길이와 컴파일 시간 사이에 입증 된 상관 관계는 없지만 평균 심볼 크기가 작을수록 모든 컴파일러의 컴파일 시간이 향상 될 수 있습니다. 따라서 첫 번째 목표는 코드에서 가장 큰 기호를 찾는 것입니다.
방법 1-크기를 기준으로 기호 정렬
nm명령을 사용하여 크기에 따라 심볼을 나열 할 수 있습니다 .
nm --print-size --size-sort --radix=d YOUR_BINARY
이 명령에서 --radix=d크기를 10 진수로 볼 수 있습니다 (기본값은 16 진). 이제 가장 큰 기호를보고 해당 클래스를 중단 할 수 있는지 확인하고 기본 클래스에서 템플릿 화되지 않은 부분을 고려하거나 클래스를 여러 클래스로 분할하여 클래스를 다시 디자인 해보십시오.
방법 2-길이를 기준으로 기호 정렬
일반 nm명령을 실행 하여 원하는 스크립트 ( AWK , Python 등)로 파이프 하여 길이 에 따라 기호를 정렬 할 수 있습니다. 우리의 경험을 바탕으로,이 방법은 방법 1보다 후보를 더 잘 만드는 가장 큰 문제를 식별합니다.
방법 3-Templight 사용
" Templight 는 템플릿 인스턴스화의 시간과 메모리 소비를 프로파일 링하고 대화 형 디버깅 세션을 수행하여 템플릿 인스턴스화 프로세스에 대한 내성을 확보 하는 Clang 기반 도구입니다."
LLVM 및 Clang ( 지침 ) 을 확인 하고 Templight 패치를 적용하여 Templight를 설치할 수 있습니다 . LLVM 및 Clang의 기본 설정은 디버그 및 어설 션에 있으며 컴파일 시간에 크게 영향을 줄 수 있습니다. Templight에 둘 다 필요한 것처럼 보이므로 기본 설정을 사용해야합니다. LLVM 및 Clang 설치 프로세스는 약 1 시간 정도 걸립니다.
패치를 적용한 후 templight++설치시 지정한 빌드 폴더에있는 코드를 사용하여 코드를 컴파일 할 수 있습니다.
templight++PATH에 있는지 확인하십시오 . 이제 컴파일하려면 CXXFLAGSMakefile 또는 명령 줄 옵션에 다음 스위치를 추가하십시오 .
CXXFLAGS+=-Xtemplight -profiler -Xtemplight -memory -Xtemplight -ignore-system
또는
templight++ -Xtemplight -profiler -Xtemplight -memory -Xtemplight -ignore-system
컴파일이 완료되면 같은 폴더에 .trace.memory.pbf 및 .trace.pbf가 생성됩니다. 이러한 추적을 시각화하기 위해 Templight 도구 를 사용하여 다른 형식으로 변환 할 수 있습니다. templight-convert를 설치하려면 다음 지시 사항 을 따르십시오 . 우리는 일반적으로 callgrind 출력을 사용합니다. 프로젝트가 작은 경우 GraphViz 출력을 사용할 수도 있습니다.
$ templight-convert --format callgrind YOUR_BINARY --output YOUR_BINARY.trace
$ templight-convert --format graphviz YOUR_BINARY --output YOUR_BINARY.dot
생성 된 callgrind 파일은 kcachegrind 를 사용하여 열 수 있으며 , 가장 많은 시간 / 메모리를 소비하는 인스턴스화를 추적 할 수 있습니다.
템플릿 인스턴스화 횟수 감소
템플릿 인스턴스화 수를 줄이는 정확한 솔루션은 없지만 다음과 같은 몇 가지 지침이 있습니다.
둘 이상의 템플릿 인수로 클래스 리팩터링
예를 들어 수업이 있으면
template <typename T, typename U>
struct foo { };
그리고 모두 T와 U10 가지 옵션을 가질 수 있습니다, 당신은이 추상적에 다른 클래스에 코드의 공통 부분 해결하기 위해 100 가지 방법으로이 클래스의 가능한 템플릿 인스턴스화를 증가하고있다. 다른 방법은 상속 계층 (클래스 계층 구조 역전)을 사용하는 것이지만이 기술을 사용하기 전에 디자인 목표가 손상되지 않는지 확인하십시오.
템플릿이 아닌 코드를 개별 번역 단위로 리팩토링
이 기술을 사용하면 공통 섹션을 한 번 컴파일하고 나중에 다른 TU (번역 단위)와 연결할 수 있습니다.
extern 템플릿 인스턴스화 사용 (C ++ 11부터)
클래스의 가능한 모든 인스턴스화를 알고 있으면이 기술을 사용하여 모든 경우를 다른 변환 단위로 컴파일 할 수 있습니다.
예를 들면 다음과 같습니다.
enum class PossibleChoices = {Option1, Option2, Option3}
template <PossibleChoices pc>
struct foo { };
이 클래스에는 세 가지 가능한 인스턴스가있을 수 있습니다.
template class foo<PossibleChoices::Option1>;
template class foo<PossibleChoices::Option2>;
template class foo<PossibleChoices::Option3>;
위의 내용을 번역 단위에 넣고 클래스 정의 아래의 헤더 파일에서 extern 키워드를 사용하십시오.
extern template class foo<PossibleChoices::Option1>;
extern template class foo<PossibleChoices::Option2>;
extern template class foo<PossibleChoices::Option3>;
이 기법을 사용하면 공통 인스턴스화 세트로 다른 테스트를 컴파일 할 때 시간을 절약 할 수 있습니다.
참고 : MPICH2는이 시점에서 명시 적 인스턴스화를 무시하고 항상 모든 컴파일 단위에서 인스턴스화 된 클래스를 컴파일합니다.
화합 빌드 사용
유니티 빌드의 기본 아이디어는 하나의 파일에 사용하는 모든 .cc 파일을 포함하고 해당 파일을 한 번만 컴파일하는 것입니다. 이 방법을 사용하면 다른 파일의 공통 섹션을 다시 인스턴스화하지 않고 프로젝트에 많은 공통 파일이 포함 된 경우 디스크 액세스에도 저장할 수 있습니다.
예를 들어,의 당신이 세 개의 파일이 있다고 가정하자 foo1.cc, foo2.cc, foo3.cc그들은 모두 포함 tuple에서 STL . foo-all.cc다음과 같은 모양을 만들 수 있습니다 .
#include "foo1.cc"
#include "foo2.cc"
#include "foo3.cc"
이 파일을 한 번만 컴파일하면 세 파일 간의 공통 인스턴스가 줄어 듭니다. 개선이 중요한지 아닌지를 일반적으로 예측하기는 어렵습니다. 그러나 한 가지 분명한 사실은 빌드에서 병렬 처리 가 손실 된다는 것입니다 (더 이상 세 파일을 동시에 컴파일 할 수 없음).
또한 이러한 파일 중 하나라도 많은 메모리를 사용하는 경우 컴파일이 끝나기 전에 실제로 메모리가 부족할 수 있습니다. GCC 와 같은 일부 컴파일러에서는 메모리 부족으로 인해 컴파일러에 ICE (Internal Compiler Error)가 발생할 수 있습니다. 따라서 모든 장단점을 알고 있지 않으면이 기술을 사용하지 마십시오.
미리 컴파일 된 헤더
PCH (사전 컴파일 된 헤더)는 헤더 파일을 컴파일러가 인식 할 수있는 중간 표현으로 컴파일하여 컴파일 시간을 크게 절약 할 수 있습니다. 사전 컴파일 된 헤더 파일을 생성하려면 일반 컴파일 명령으로 헤더 파일 만 컴파일하면됩니다. 예를 들어 GCC에서 :
$ g++ YOUR_HEADER.hpp
이것은이 생성됩니다 YOUR_HEADER.hpp.gch file( .gch같은 폴더에 GCC에서 PCH 파일의 확장자입니다). 즉 YOUR_HEADER.hpp, 다른 파일에 포함하면 컴파일러가 이전에 동일한 폴더 YOUR_HEADER.hpp.gch대신 사용합니다 YOUR_HEADER.hpp.
이 기술에는 두 가지 문제가 있습니다.
- 미리 컴파일 된 헤더 파일이 안정적이며 변경되지 않는지 확인해야합니다 ( 언제나 makefile을 변경할 수 있습니다 )
- 컴파일 장치 당 하나의 PCH 만 포함 할 수 있습니다 (대부분의 컴파일러에서). 즉, 미리 컴파일 할 헤더 파일이 두 개 이상인 경우 하나의 파일 (예 :)에 포함시켜야합니다
all-my-headers.hpp. 그러나 이것은 모든 장소에 새로운 파일을 포함시켜야한다는 것을 의미합니다. 다행히도 GCC는이 문제에 대한 해결책을 가지고 있습니다. 사용 -include하고 그것을 새로운 헤더 파일을 제공합니다. 이 기술을 사용하여 쉼표로 다른 파일을 분리 할 수 있습니다.
예를 들면 다음과 같습니다.
g++ foo.cc -include all-my-headers.hpp
이름이 없거나 익명 인 네임 스페이스 사용
익명 네임 스페이스 ( 명명없는 네임 스페이스)는 생성 된 이진 크기를 크게 줄일 수 있습니다. 명명되지 않은 네임 스페이스는 내부 연결을 사용하므로 해당 네임 스페이스에서 생성 된 심볼은 다른 TU (번역 또는 컴파일 단위)에 표시되지 않습니다. 컴파일러는 일반적으로 명명되지 않은 네임 스페이스에 대해 고유 한 이름을 생성합니다. 이는 foo.hpp 파일이있는 경우 다음을 의미합니다.
namespace {
template <typename T>
struct foo { };
} // Anonymous namespace
using A = foo<int>;
그리고이 파일을 두 개의 TU (2 개의 .cc 파일과 별도로 컴파일)에 포함시킵니다. 두 개의 foo 템플릿 인스턴스는 동일하지 않습니다. 이는 하나의 정의 규칙 (ODR)을 위반합니다 . 같은 이유로 이름없는 네임 스페이스를 사용하는 것은 헤더 파일에서 사용하지 않는 것이 좋습니다. .cc이진 파일에 기호가 표시되지 않도록 파일 에서 자유롭게 사용 하십시오. 경우에 따라 .cc파일의 모든 내부 세부 정보를 변경 하면 생성 된 이진 크기가 10 % 감소한 것으로 나타났습니다.
가시성 옵션 변경
최신 컴파일러에서는 동적 공유 객체 (DSO)에서 심볼이 표시되거나 보이지 않도록 선택할 수 있습니다. 가시성을 변경하면 컴파일러 성능, 링크 시간 최적화 (LTO) 및 생성 된 이진 크기를 개선 할 수 있습니다. GCC에서 STL 헤더 파일을 보면 널리 사용되는 것을 볼 수 있습니다. 가시성 선택을 가능하게하려면 함수, 클래스, 변수 및 더 중요하게는 컴파일러마다 코드를 변경해야합니다.
가시성의 도움으로 생성 된 공유 객체에서 개인으로 간주되는 심볼을 숨길 수 있습니다. GCC에서는 -visibility컴파일러 옵션에 기본값을 숨기거나 숨겨서 기호의 가시성을 제어 할 수 있습니다 . 이것은 이름이없는 네임 스페이스와 비슷하지만보다 정교하고 방해가되는 방식입니다.
사례 당 가시성을 지정하려면 함수, 변수 및 클래스에 다음 속성을 추가해야합니다.
__attribute__((visibility("default"))) void foo1() { }
__attribute__((visibility("hidden"))) void foo2() { }
__attribute__((visibility("hidden"))) class foo3 { };
void foo4() { }
GCC의 기본 가시성은 공유 라이브러리 (로 위의 컴파일하는 경우 즉, 기본 (공개)이다 -shared) 방법, foo2및 클래스가 foo3다른 TU가에 표시되지 않습니다 ( foo1및 foo4표시됩니다). 당신이 컴파일하는 경우 -visibility=hidden만 foo1표시됩니다. 비록 foo4숨겨져있을 것입니다.
GCC wiki에서 가시성에 대해 자세히 읽을 수 있습니다 .