컴파일 시간이 매우 느려 듀얼 코어 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 빌드 구성 만 사용하는 것이 가장 좋습니다.

이것이 C 또는 C ++이고 사전 컴파일 된 헤더를 사용하지 않는 경우 있어야합니다.

우리는 메인 솔루션에 80 개 이상의 프로젝트를 진행했으며 개발자가 어떤 종류의 기계를 사용 하느냐에 따라 빌드하는 데 약 4-6 분이 걸렸습니다. 우리는이 방법이 너무 길다고 생각했습니다. 매 테스트마다 FTE가 실제로 사라집니다.

그렇다면 더 빠른 빌드 시간을 얻는 방법은 무엇입니까? 당신이 이미 알고있는 것처럼 그것은 실제로 빌드 타임을 해친 프로젝트의 수입니다. 물론 우리는 모든 프로젝트를 없애고 모든 소스 파일을 하나로 던져 버리고 싶지 않았습니다. 그러나 우리는 그럼에도 불구하고 우리가 결합 할 수있는 몇 가지 프로젝트를 수행했습니다. 솔루션의 모든 "리포지토리 프로젝트"에는 자체 단위 테스트 프로젝트가 있으므로 모든 단위 테스트 프로젝트를 하나의 글로벌 단위 테스트 프로젝트로 결합했습니다. 약 12 개의 프로젝트로 프로젝트 수를 줄이고 전체 솔루션을 구축하는 데 소요되는 시간을 40 % 절약했습니다.

우리는 다른 해결책에 대해 생각하고 있습니다.

새 프로젝트로 새로운 (두 번째) 솔루션을 설정하려고 했습니까? 이 두 번째 솔루션은 솔루션 폴더를 사용하여 모든 파일을 간단히 통합해야합니다. 새로운 솔루션이 하나만있는 프로젝트의 빌드 시간을보고 놀랄 수도 있습니다.

그러나 두 가지 다른 솔루션을 사용하려면 신중하게 고려해야합니다. 개발자는 실제로 두 번째 솔루션에서 작업을하고 첫 번째 솔루션을 완전히 무시하는 경향이 있습니다. 70 개 이상의 프로젝트가 포함 된 첫 번째 솔루션은 객체 계층 구조를 관리하는 솔루션이므로 빌드 서버가 모든 단위 테스트를 실행해야하는 솔루션이어야합니다. 따라서 연속 통합 서버는 첫 번째 프로젝트 / 솔루션이어야합니다. 객체 계층을 유지해야합니다.

모든 개발자가 테스트 및 디버깅을 수행하는 프로젝트보다 하나의 프로젝트 (훨씬 더 빠르게 구축 됨)가있는 두 번째 솔루션이 될 것입니다. 그래도 빌드 서버를 보면서 그들을 돌봐야합니다! 파손 된 것이 있으면 반드시 고정해야합니다.

라이브러리 출력 디렉토리의 DLL에 대한 참조가 아닌 프로젝트 참조가 프로젝트 참조인지 확인하십시오.

또한 필요한 경우를 제외하고 로컬로 복사하지 않도록 설정하십시오 (마스터 EXE 프로젝트).

이 응답을 원래 여기에 게시했습니다. /programming/8440/visual-studio-optimizations#8473 해당 페이지에서 다른 유용한 힌트를 찾을 수 있습니다.

Visual Studio 2008을 사용하는 경우 / MP 플래그를 사용하여 컴파일하여 단일 프로젝트를 병렬로 빌드 할 수 있습니다. Visual Studio 2005에서 문서화되지 않은 기능이지만 직접 시도한 적이 없다는 것을 읽었습니다.

/ M 플래그를 사용하여 여러 프로젝트를 병렬로 빌드 할 수 있지만 일반적으로 머신에서 사용 가능한 코어 수로 설정되어 있지만 VC ++에만 적용됩니다.

나는이 질문이 오래되었지만 오늘날에도 여전히 관심의 대상이되고 있습니다. 같은 문제가 최근에 저를 깨웠고 빌드 성능을 가장 향상시킨 두 가지 사항은 (1) 컴파일에 전용 (빠른) 디스크를 사용하고 (2) 모든 프로젝트에 동일한 출력 폴더를 사용하고 프로젝트에서 CopyLocal을 False로 설정하는 것이 었습니다. 참조.

몇 가지 추가 자료 :

• /programming/8440/visual-studio-optimizations
• http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx
• http://arnosoftwaredev.blogspot.com/2010/05/how-to-improve-visual-studio-compile.html
• http://blog.brianhartsock.com/2009/12/22/analyzing-visual-studio-build-performance/

일부 분석 도구 :

도구-> 옵션-> VC ++ 프로젝트 설정-> 빌드 타이밍 = 예는 모든 vcproj에 대한 빌드 시간을 알려줍니다.

/Bt컴파일러 명령 행에 스위치를 추가 하여 모든 CPP 파일의 소요량을 확인하십시오

사용 /showIncludes중첩 캐치로는 (다른 헤더 파일을 포함 헤더 파일)을 포함하고 파일 앞으로 선언을 사용하여 IO를 많이 절약 할 수 무엇을 참조하십시오.

이는 의존성과 성능 호그를 제거하여 컴파일러 성능을 최적화하는 데 도움이됩니다.

더 빠른 하드 드라이브에 투자하기 위해 돈을 소비하기 전에 RAM을 절약 할 수 있다고 가정하여 RAM 디스크에 프로젝트를 완전히 구축하십시오. 인터넷에서 다양한 무료 RAM 디스크 드라이버를 찾을 수 있습니다. RAM 디스크보다 빠른 SSD를 포함한 물리적 드라이브는 찾을 수 없습니다.

필자의 경우 Incredibuild를 사용하는 7200 RPM SATA 드라이브에서 6 코어 i7을 빌드하는 데 5 분이 걸리는 프로젝트는 RAM 디스크를 사용하여 약 15 초만 단축되었습니다. 영구 저장 장치로 다시 복사해야 할 필요성과 작업 손실 가능성을 고려할 때, 15 초는 RAM 디스크를 사용하는 데 충분한 인센티브가 아니며 높은 RPM 또는 SSD 드라이브에 수백 달러를 소비 할 인센티브가 아닙니다.

작은 게인은 빌드가 CPU 바운드이거나 Windows 파일 캐싱이 다소 효과적 이었음을 나타낼 수 있지만 두 테스트는 파일이 캐시되지 않은 상태에서 수행되었으므로 CPU 바운드 컴파일에 크게 의존합니다.

실제 코드에 따라 마일리지를 컴파일하는 방법이 다를 수 있으므로 주저하지 말고 테스트하십시오.

완전한 빌드를 한 후 빌드 디렉토리는 얼마나 큽니까? 기본 설정을 고수하면 빌드하는 모든 어셈블리가 해당 종속성의 모든 DLL 및 해당 종속성의 종속성 등을 bin 디렉토리에 복사합니다. ~ 40 프로젝트의 솔루션으로 작업 할 때의 이전 작업에서 동료들은 빌드 프로세스에서 가장 비싼 부분이 이러한 어셈블리를 반복해서 복사하는 것이고 하나의 빌드로 동일한 DLL의 기가 바이트 사본을 생성 할 수 있음을 발견했습니다. 다시.

다음은 NDepend의 저자 인 Patrick Smacchia의 개별 조언이되어야한다고 생각되는 내용에 대한 유용한 조언입니다.

http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

기본적으로이 문제를 해결할 수있는 두 가지 방법이 있으며 둘 다 단점이 있습니다. 하나는 많은 수의 어셈블리를 줄이는 것입니다. 다른 하나는 모든 bin 폴더가 통합되고 프로젝트가 종속성의 DLL을 복사하지 않도록 빌드 디렉토리를 재구성하는 것입니다. 모두 동일한 디렉토리에 있기 때문에 필요하지 않습니다. 이렇게하면 빌드 중에 작성 및 복사되는 파일 수가 크게 줄어들지 만 설정하기가 어려울 수 있으며 패키징을 위해 특정 실행 파일에 필요한 DLL 만 꺼내기가 어려워 질 수 있습니다.

아마도 몇 가지 공통 기능을 수행하고 라이브러리를 여러 개 만들면 여러 프로젝트에서 동일한 소스가 반복해서 컴파일되지 않습니다.

다른 버전의 DLL이 혼동되는 것이 걱정되면 정적 라이브러리를 사용하십시오.

VSS 통합을 끕니다. 당신은 그것을 사용하는 선택이 없을 수도 있지만, DLL은 항상 "우연히"이름이 변경됩니다 ...

미리 컴파일 된 헤더 설정을 확인하십시오. 브루스 도슨의 가이드가 여전히 조금 오래된,하지만이며 매우 좋은 - 그것을 체크 아웃 : http://www.cygnus-software.com/papers/precompiledheaders.html

120 개 이상의 exe, libs 및 dll이 있고 빌드하는 데 상당한 시간이 걸리는 프로젝트가 있습니다. 하나의 마스터 배치 파일에서 make 파일을 호출하는 배치 파일 트리를 사용합니다. 나는 과거에 증분 (또는 기 질적 인) 헤더에서 이상한 일에 문제가 있었으므로 지금 피할 수 있습니다. 나는 종종 전체 빌드를하지 않으며, 한 시간 동안 산책을하는 동안 일반적으로 하루의 끝까지 두십시오 (그래서 약 30 분 정도 걸리는 것으로 추측 할 수 있습니다). 그래서 왜 작동 및 테스트가 불가능한지 이해합니다.

작업 및 테스트를 위해 각 앱 (또는 모듈 또는 라이브러리)에 대한 모든 배치 설정이있는 배치 파일 세트가 있지만 여전히 동일한 make 파일을 호출합니다. 때때로 DEBUG를 끄고 빌드 또는 빌드를 결정하거나 모듈이 의존 할 수있는 라이브러리를 빌드할지 여부 등을 결정할 수 있습니다.

배치 파일은 완성 된 결과를 여러 테스트 폴더에 복사합니다. 설정에 따라이 과정은 몇 초에서 1 분 안에 완료됩니다 (30 분의 30이 아닌).

.rc 파일과 같은 것을 제어하고 싶기 때문에 다른 IDE (Zeus)를 사용했으며 실제로 MS 컴파일러를 사용하더라도 명령 줄에서 컴파일하는 것을 선호합니다.

관심이 있다면이 배치 파일의 예를 게시 해 드리겠습니다.

소스 디렉토리 (특히 소스를 검색 할 수있게하려면 obj 디렉토리)에서 파일 시스템 색인 작성을 사용 불가능하게하십시오.

이것이 웹앱 인 경우 배치 빌드를 true로 설정하면 시나리오에 따라 도움이 될 수 있습니다.

<compilation defaultLanguage="c#" debug="true" batch="true" >  

여기에서 개요를 찾을 수 있습니다 : http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

순환 프로젝트 참조를 확인할 수도 있습니다. 한 번만 문제였습니다.

그건:

프로젝트 A는 프로젝트 B를 참조합니다

프로젝트 B는 프로젝트 C를 참조합니다

프로젝트 C는 프로젝트 A를 참조합니다

Xoreax IB의 저렴한 대안 중 하나는 내가 uber 파일 빌드라고 부르는 것입니다. 기본적으로 .cpp 파일입니다.

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

그런 다음 개별 모듈 대신 uber 단위를 컴파일하십시오. 컴파일 시간은 10-15 분에서 1-2 분으로 줄었습니다. uber 파일 당 몇 개의 #include를 포함하는지 이해해야 할 수도 있습니다. 프로젝트에 따라 다릅니다. 10 개 파일, 20 개 파일을 포함 할 수 있습니다.

당신은 비용을 지불하므로주의하십시오 :

1. 빌드에서 개별 cpp 파일을 제외하고 uber cpp 파일 만 포함해야하므로 파일을 마우스 오른쪽 단추로 클릭하고 "컴파일 ..."이라고 말할 수 없습니다.
2. 정적 전역 변수 충돌에주의해야합니다.
3. 새 모듈을 추가 할 때 uber 파일을 최신 상태로 유지해야합니다

그것은 일종의 고통이지만 새로운 모듈 측면에서 크게 정적 인 프로젝트의 경우 초기 통증이 그만한 가치가 있습니다. 경우에 따라이 방법이 IB를 능가하는 것을 보았습니다.

C ++ 프로젝트 인 경우 사전 컴파일 된 헤더를 사용해야합니다. 이것은 컴파일 시간에 큰 차이를 만듭니다. cl.exe가 실제로 수행하는 작업 (미리 컴파일 된 헤더를 사용하지 않음)을 모르는 경우 올바른 위치로 이동하기 전에 모든 잘못된 위치에서 많은 STL 헤더를 찾고있는 것 같습니다 . 이렇게하면 컴파일되는 모든 단일 .cpp 파일에 초 전체가 추가됩니다. 이것이 cl.exe 버그인지 또는 VS2008의 STL 문제인지 확실하지 않습니다.

구축중인 머신을보고 최적으로 구성되어 있습니까?

방대한 C ++ 엔터프라이즈 급 제품의 빌드 시간이 19 시간 에서 16 분으로 단축 되었습니다.올바른 SATA 필터 드라이버가 설치되어 으로 .

세밀한.

Visual Studio 2005에는 문서화되지 않은 / MP 스위치가 있습니다 ( http://lahsiv.net/blog/?p=40 참조 ). 이는 프로젝트 단위가 아닌 파일 단위로 병렬 컴파일을 가능하게합니다. 이렇게하면 마지막 프로젝트의 컴파일 속도가 빨라지거나 하나의 프로젝트를 컴파일하는 경우 속도가 빨라질 수 있습니다.

CPU를 선택할 때 : L1 캐시 크기는 컴파일 시간에 큰 영향을 미치는 것으로 보입니다. 또한 일반적으로 4 개의 느린 코어보다 2 개의 빠른 코어를 사용하는 것이 좋습니다. Visual Studio는 추가 코어를 매우 효과적으로 사용하지 않습니다. (C ++ 컴파일러에 대한 경험을 바탕으로하지만 C # 컴파일러에서도 마찬가지입니다.)

또한 VS2008에 문제가 있다고 확신합니다. 안티 바이러스를 끈 상태에서 3G Ram이 장착 된 듀얼 코어 Intel 랩탑에서 실행하고 있습니다. 솔루션을 컴파일하는 것은 종종 매끄럽지 만, 디버깅을 계속하면 크롤링 속도가 느려질 수 있습니다. 연속 주 디스크 표시 등에서 디스크 I / O 병목 현상이 있음을 알 수 있습니다 (이 또한 들립니다). 빌드를 취소하고 VS를 종료하면 디스크 작업이 중지됩니다. VS를 다시 시작하고 솔루션을 다시로드 한 다음 다시 빌드하면 훨씬 빠릅니다. 다음 번에 Unitl

내 생각에는 이것이 메모리 페이징 문제라고 생각합니다 .VS는 메모리가 부족하고 공간을 만들기 위해 페이지 교환을 시작하지만 VS는 페이지 교환이 제공 할 수있는 것보다 많은 것을 요구하므로 크롤링 속도가 느려집니다. 다른 설명은 생각할 수 없습니다.

VS는 확실히 RAD 도구가 아닙니다.

귀사에서 PKI / 암호화 솔루션으로 Entrust를 우연히 사용합니까? 우리는 Rebuild-All에서 7 분 이상 걸리는 C #으로 구축 된 상당히 큰 웹 사이트에 대한 끔찍한 빌드 성능을 보였습니다.

내 컴퓨터는 16GB 램과 512GB SSD를 갖춘 i7-3770이므로 성능이 그렇게 나쁘지 않아야합니다. 동일한 코드베이스를 구축하는 구형 보조 시스템에서 빌드 시간이 엄청나게 빨랐습니다. 그래서 두 컴퓨터에서 ProcMon을 시작하고 빌드를 프로파일 링하고 결과를 비교했습니다.

Lo-be, 성능이 느린 기계는 스택 트레이스에서 Entrust.dll에 대한 참조와 한 가지 차이점이 있습니다. 이 새로 얻은 정보를 사용하여 StackOverflow를 계속 검색하고 다음을 발견했습니다. 일부 컴퓨터에서 MSBUILD (VS2010)가 매우 느림 . 수락 된 답변에 따르면 문제는 Entrust 처리기가 기본 Microsoft 처리기 대신 .NET 인증서 검사를 처리하고 있다는 사실에 있습니다. 또한 Tt는 Entrust v10이 Entrust 9에서 흔히 발생하는이 문제를 해결하도록 제안합니다.

나는 현재 그것을 제거하고 내 빌드 시간은 24 초로 떨어졌다 . YYMV는 현재 빌드중인 프로젝트 수이며 문의 한 스케일링 문제를 직접 해결하지 못할 수 있습니다. 소프트웨어 제거에 의존 하지 않고 수정 사항 을 제공 할 수 있으면이 응답에 대한 편집 내용을 게시 할 것 입니다.

VS2008에 문제가 있다고 확신합니다. 내가 한 유일한 일은 VS2005로 만든 프로젝트를 업그레이드하기 위해 VS2008을 설치하는 것입니다. 내 솔루션에는 2 개의 프로젝트 만 있습니다. 크지 않습니다. VS2005로 컴파일 : 30 초 VS2008로 컴파일 : 5 분

지금까지 도움이 된 좋은 제안 (아래에 다른 좋은 제안이 없다고 말하지 않고 문제가있는 경우 읽을 것을 권장합니다.)

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

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

또한 새로운 솔루션으로 애플리케이션의 새로운 영역을 구축하고 필요에 따라 최신 dll을 가져 와서 더 큰 솔루션으로 통합하는 방법을 테스트하고 있습니다.

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

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