[C#] Visual Studio 2005에서 컴파일 시간이 매우 느림

C# / 글쓴이

컴파일 시간이 매우 느려 듀얼 코어 2GHz, 2G Ram 머신에서 20 분 이상이 걸릴 수 있습니다.

이것은 많은 파일이있을 때 병목 인 VSS뿐만 아니라 70 개 이상의 프로젝트로 성장한 솔루션의 크기 때문입니다. (VSS 스왑 아웃은 불행히도 옵션이 아니므로 VSS bash로 내려 가기를 원하지 않습니다)

우리는 프로젝트 병합을보고 있습니다. 또한 응용 프로그램의 각 요소에 대해 더 큰 관심사 분리 및 빠른 컴파일 시간을 달성 할 수있는 여러 솔루션이 필요합니다. 우리가 볼 수있는 것을 동기화하려고하면 DLL 지옥이 될 것입니다.

다른 팀 이이 스케일링 문제를 어떻게 처리했는지 알고 싶습니다. 코드베이스가 상태 표시 줄이 컴파일 메시지를 전달하는 것을 반나절 낭비하고있는 임계 질량에 도달하면 어떻게해야합니까?

업데이트
나는 이것이 C # 솔루션이라고 언급하지 않았습니다. 모든 C ++ 제안에 감사하지만 헤더에 대해 걱정 한 지 몇 년이되었습니다.

편집하다:

지금까지 도움이 된 좋은 제안 (아래에 다른 좋은 제안이 없다고 말하지 않고 도움이 된 것)

  • 새로운 3GHz 랩톱-사용률 손실의 힘으로 경영진이 궁금해합니다
  • 컴파일 중 안티 바이러스 비활성화
  • 컴파일하는 동안 VSS (실제로 네트워크)에서 ‘연결 끊기’-VS-VSS 통합을 완전히 제거하고 VSS UI 사용을 고수 할 수 있습니다.

여전히 컴파일을 통해 찢어지지는 않지만 모든 비트가 도움이됩니다.

오리온은 제네릭도 놀이를 할 수 있다고 언급했다. 내 테스트에서 최소한의 성능 저하가 있지만 확실하게 충분히 높지 않은 것으로 보입니다. 디스크 활동으로 인해 컴파일 시간이 일치하지 않을 수 있습니다. 시간 제한으로 인해 내 테스트에는 라이브 시스템에 나타나는만큼 많은 제네릭이나 코드가 포함되지 않아 누적 될 수 있습니다. 컴파일 타임 성능을 위해 제네릭을 사용해야하는 곳에서는 제네릭을 사용하지 마십시오.

해결 방법

우리는 새로운 솔루션으로 새로운 응용 프로그램 영역을 구축하고 필요한 최신 dll을 가져 와서 만족할 때 더 큰 솔루션으로 통합하는 방법을 테스트하고 있습니다.

또한 작업해야 할 영역을 캡슐화하고 코드를 다시 통합 한 후 버리는 임시 솔루션을 만들어 기존 코드와 동일하게 수행 할 수도 있습니다. 우리는 Rip Van Winkle이 개발 중 빠른 재 컴파일 경험과 같은 경험을 얻지 못함으로써이 코드를 재 통합하는 데 걸리는 시간을 측정해야합니다.

답변

Chromium.org 팀 은 빌드 를 가속화하기 위한 몇 가지 옵션을 나열했습니다 (이 시점에서 페이지의 반쯤 가까워짐).

속도 증가 순서 :

  • Microsoft 핫픽스 935225를 설치하십시오 .
  • Microsoft 핫픽스 947315를 설치하십시오 .
  • 진정한 멀티 코어 프로세서 (예 : Pentium 4 HT가 아닌 Intel Core Duo 2)를 사용하십시오.
  • 3 개의 병렬 빌드를 사용하십시오. Visual Studio 2005의 경우 도구> 옵션 …> 프로젝트 및 솔루션> 빌드 및 실행> 최대 병렬 프로젝트 빌드 수에서 옵션을 찾을 수 있습니다.
  • .ilk, .pdb, .cc, .h 파일에 대한 안티 바이러스 소프트웨어를 비활성화하고 수정시 바이러스 만 검사하십시오 . 소스가있는 디렉토리를 스캔하지 마십시오. 바보 같은 짓을하지 마십시오.
  • 두 번째 하드 드라이브에 Chromium 코드를 저장하고 빌드하십시오. 실제로 빌드 속도를 높이지는 않지만 gclient 동기화 또는 빌드를 수행 할 때 최소한 컴퓨터는 반응을 유지합니다.
  • 정기적으로 하드 드라이브 조각 모음을 수행하십시오.
  • 가상 메모리를 비활성화하십시오.

답변

하나의 솔루션에 거의 100 개의 프로젝트가 있으며 단 몇 초의 개발 시간이 있습니다. 🙂

지역 발전을 위해 우리가 변화하는 비주얼 스튜디오 추가 기능을 만들어 빌드 Project references에 DLL references원치 않는 프로젝트 언로드 (및 옵션이 다시 과정을 전환합니다).

  • 전체 솔루션을 한 번 구축
  • 현재 작업하고 있지 않은 프로젝트를 언로드하고 모든 프로젝트 참조를 DLL 참조로 변경하십시오.
  • 체크인하기 전에 모든 참조를 DLL에서 프로젝트 참조로 다시 변경하십시오.

빌드는 한 번에 몇 개의 프로젝트 만 수행 할 때 몇 초 밖에 걸리지 않습니다. 또한 디버그 DLL에 연결되는 추가 프로젝트를 디버깅 할 수도 있습니다. 이 도구는 일반적으로 많은 수의 변경 작업을 수행하는 데 10-30 초가 걸리지 만 자주 수행 할 필요는 없습니다.

2015 년 5 월 업데이트

나는 (아래 설명에서) 만들어 거래는, 내가 오픈 소스에 플러그인을 출시한다고했다 경우 충분히 관심을 가져옵니다. 4 년 후 44 표를 얻었으며 (Visual Studio에는 현재 두 개의 후속 버전이 있음) 현재 우선 순위가 낮은 프로젝트입니다.

답변

21 개의 프로젝트와 1/2 백만 개의 LOC가있는 솔루션에 대해서도 비슷한 문제가있었습니다. 가장 큰 차이점은 더 빠른 하드 드라이브를 얻는 것이 었습니다. 실적 모니터에서 ‘Avg. 노트북에서 Disk Queue ‘가 크게 올라가 하드 드라이브가 병목 상태임을 나타냅니다.

총 재 구축 시간에 대한 데이터는 다음과 같습니다.

1) 랩톱, Core 2 Duo 2GHz, 5400 RPM 드라이브 (캐시가 확실하지 않습니다. 표준 Dell inspiron이었습니다).

재건 시간 = 112 초

2) 데스크톱 (표준 문제), Core 2 Duo 2.3Ghz, 단일 7200RPM 드라이브 8MB 캐시.

재건 시간 = 72 초

3) 데스크탑 코어 2 듀오 3Ghz, 단일 10000 RPM WD 랩터

재건 시간 = 39 초

10,000RPM 드라이브는 과소 평가 될 수 없습니다. 파일 탐색기를 사용하여 문서 표시와 같은 다른 모든 것이 훨씬 더 빨라진 빌드는 눈에 띄게 빨라졌습니다. 코드 빌드 실행주기를 단축하여 생산성을 크게 향상 시켰습니다.


회사가 개발자 급여에 지출하는 비용을 고려할 때 접수 담당자가 사용하는 것과 동일한 PC를 장착하여 구매 비용을 얼마나 낭비 할 수 있는지는 미쳤 습니다.

답변

C # .NET 빌드의 경우 .NET Demon을 사용할 수 있습니다 . Visual Studio 빌드 프로세스를 대신하여 더 빠르게 만드는 제품입니다.

변경 내용을 분석하고 실제로 변경 한 프로젝트와 실제로 변경 한 내용에 의존 한 다른 프로젝트 만 빌드합니다. 즉, 내부 코드 만 변경하면 하나의 프로젝트 만 빌드하면됩니다.

답변

안티 바이러스를 끕니다. 컴파일 시간을 연장시킵니다.

답변

분산 컴파일을 사용하십시오. Xoreax IncrediBuild 는 컴파일 시간을 몇 분으로 줄일 수 있습니다.

나는 그것을 컴파일하는 데 보통 5-6 시간이 걸리는 거대한 C \ C ++ 솔루션에서 사용했습니다. IncrediBuild는이 시간을 15 분으로 줄였습니다.

답변

Visual Studio 컴파일 시간을 몇 초로 단축하기위한 지침

불행히도 Visual Studio는 어셈블리의 인터페이스 변경을 중요하지 않은 코드 본문 변경과 구별하기에 충분히 영리하지 않습니다. 이 사실은 큰 얽힌 솔루션과 결합 될 때, 한 줄의 코드를 변경할 때마다 원치 않는 ‘전체 빌드’에 대한 완벽한 폭풍을 만들 수 있습니다.

이를 극복하기위한 전략은 자동 참조 트리 빌드를 비활성화하는 것입니다. 이렇게하려면 ‘Configuration Manager'(빌드 / 구성 관리자 … Active 솔루션 구성 드롭 다운에서 ‘New’선택)를 사용하여 디버그 구성에서 복사하는 ‘ManualCompile’이라는 새 빌드 구성을 작성하십시오. ‘새 프로젝트 구성 만들기’확인란을 선택하지 마십시오. 이 새 빌드 구성에서 모든 프로젝트를 선택 취소하면 자동으로 빌드되지 않습니다. ‘닫기’를 눌러이 구성을 저장하십시오. 이 새로운 빌드 구성이 솔루션 파일에 추가됩니다.

IDE 화면 상단의 빌드 구성 드롭 다운 (보통 ‘Debug’또는 ‘Release’가 표시됨)을 통해 하나의 빌드 구성에서 다른 빌드 구성으로 전환 할 수 있습니다. 효과적으로이 새로운 ManualCompile 빌드 구성은 ‘Build Solution’또는 ‘Rebuild Solution’에 대한 Build 메뉴 옵션을 쓸모 없게 만듭니다. 따라서 수동 컴파일 모드 인 경우 수정중인 각 프로젝트를 수동으로 빌드해야합니다. 솔루션 탐색기에서 영향을받는 각 프로젝트를 마우스 오른쪽 단추로 클릭 한 다음 ‘빌드’또는 ‘재 빌드’를 선택하면됩니다. 전체 컴파일 시간이 단 몇 초에 불과하다는 것을 알 수 있습니다.

이 전략이 작동하려면 AssemblyInfo 및 GlobalAssemblyInfo 파일에있는 VersionNumber가 개발자의 컴퓨터에서 정적 상태를 유지해야하며 (릴리스 빌드 중에는 물론) DLL에 서명하지 않아야합니다.

이 ManualCompile 전략을 사용하는 잠재적 인 위험은 개발자가 필요한 프로젝트를 컴파일하는 것을 잊어 버릴 수 있고 디버거를 시작할 때 예기치 않은 결과 (디버거를 첨부 할 수 없음, 파일을 찾을 수 없음 등)가 발생한다는 것입니다. 이를 피하려면 더 큰 코딩 노력을 컴파일하기 위해 ‘디버그’빌드 구성을 사용하는 것이 가장 좋으며, 단위 테스트 중 또는 범위가 제한된 빠른 변경을 수행 할 때 ManualCompile 빌드 구성 만 사용하는 것이 가장 좋습니다.