헤더 의존을 줄인다. 자주 변할 수 있는 코드는 헤더에 쓰지 않는다.

모듈화 하여 의존을 줄이거나 모듈을 dll화 하여 링크 시간을 단축하다(단 너무 나누는 것은 주의).

모듈별로 프로젝트를 분할하면 자연스럽게 의존이 없어지고 그 결과 프로그램 변경 시 빌드 시간 단축도 생긴다.
또 정적 링크(staticLib)에서 동적 링크(dll)로 바꾸는 것으로 링크 시간이 줄어진다.

프리 컴파일 된 헤더 / 병렬 빌드를 적절히 설정한다.

PC 성능 업그레이드

CPU 성능을 올린다.
메모리를 늘린다. 빌드 시 HDD 스왑이 줄면서 빌드(링크도?) 속도가 개선된다.
HDD → SSD로 바꾼다.

소스 코드가 너무 크고 복잡하다

프리 프로세스에 시간이 걸리거나 소스 코드가 복잡하면 빌드 시간에 영향을 주고, 빌드 후의 OBJ 파일 사이즈가 너무 크면 링크에 영향을 미친다.

복잡한 템플릿

STL 이나 boost를 사용한 것만으로 빌드 시간이 늘어났다고 느낀 경험이 있을 것이다.
프리 프로세스에서 행해지는 템플릿 해석은 빌드 시간에서 템플릿의 전개에 의한 코드 사이즈의 증가로 링크 시간에 지대한 영향을 끼치므로 템플릿은 용법 용량을 지키고 올바르게 사용해야 한다.

대량의 강제 inline

강제 inline도 비교적 위험. 처리 속도를 높이는 것만이 최적화라고 믿는 사람이 상당수 존재하므로 모든 함수를 강제 inline화 했는데 알고 보니 OBJ 사이즈가 커져서, 빌드 시간이나 링크 시간에 영향을 미쳤다. 최대한 inline화는 우리보다 몇 배 똑똑한 컴파일러에게 맡기도록 한다.

엄청나게 큰 static 영역이 잔뜩(그렇게 영향 없을지도?)

소스에 엄청나게 큰 static한 배열이 있으면 OBJ의 사이즈가 크게 된다. 강제 inline이나, 과격 한 templete 사용이 없는데도 왠지 링크 시간이 너무 많이 걸리는 경우는 static이 원인 일수도 있다.