Visual Studio 2005에서 컴파일 시간이 매우 느림
컴파일 시간이 매우 느려 듀얼 코어 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 화면 상단의 빌드 구성 드롭 다운 (일반적으로 '디버그'또는 '릴리스'가 표시되는)을 통해 하나의 빌드 구성에서 다른 빌드 구성으로 전환 할 수 있습니다. 효과적으로이 새로운 ManualCompile 빌드 구성은 'Build Solution'또는 'Rebuild Solution'에 대한 Build 메뉴 옵션을 쓸모 없게 만듭니다. 따라서 수동 컴파일 모드 인 경우 수정중인 각 프로젝트를 수동으로 빌드해야합니다. 솔루션 탐색기에서 영향을받는 각 프로젝트를 마우스 오른쪽 단추로 클릭 한 다음 '빌드'또는 '재 빌드'를 선택하면됩니다. 전체 컴파일 시간이 단 몇 초에 불과하다는 것을 알 수 있습니다.
이 전략이 작동하려면 AssemblyInfo 및 GlobalAssemblyInfo 파일에있는 VersionNumber가 개발자의 컴퓨터에서 정적 상태를 유지해야하며 (릴리스 빌드 중에는 물론) DLL에 서명하지 않아야합니다.
이 ManualCompile 전략을 사용하는 잠재적 인 위험은 개발자가 필요한 프로젝트를 컴파일하지 않고 디버거를 시작할 때 예기치 않은 결과 (디버거를 첨부 할 수 없음, 파일을 찾을 수 없음 등)를 얻는다는 것입니다. 이를 피하려면 더 큰 코딩 노력을 컴파일하기 위해 '디버그'빌드 구성을 사용하는 것이 가장 좋으며 단위 테스트 중 또는 범위가 제한된 빠른 변경을 수행하는 경우에만 ManualCompile 빌드 구성을 사용하는 것이 가장 좋습니다.
이것이 C 또는 C ++이고 사전 컴파일 된 헤더를 사용하지 않는 경우 있어야합니다.
우리는 메인 솔루션에 80 개 이상의 프로젝트를 진행했으며 개발자가 어떤 종류의 기계를 사용 하느냐에 따라 빌드하는 데 약 4-6 분이 걸렸습니다. 우리는이 방법이 너무 길다고 생각했습니다. 매 테스트마다 FTE가 실제로 사라집니다.
그렇다면 더 빠른 빌드 시간을 얻는 방법은 무엇입니까? 당신이 이미 알고있는 것처럼 그것은 실제로 빌드 타임을 해친 프로젝트의 수입니다. 물론 우리는 모든 프로젝트를 없애고 모든 소스 파일을 하나로 던져 버리고 싶지 않았습니다. 그러나 우리는 그럼에도 불구하고 우리가 결합 할 수있는 몇 가지 프로젝트를 가졌습니다. 솔루션의 모든 "리포지토리 프로젝트"에는 자체 단위 테스트 프로젝트가 있으므로 모든 단위 테스트 프로젝트를 하나의 글로벌 단위 테스트 프로젝트로 결합했습니다. 약 12 개의 프로젝트로 프로젝트 수를 줄이고 전체 솔루션을 구축하는 데 소요되는 시간을 40 % 절약했습니다.
우리는 다른 해결책에 대해 생각하고 있습니다.
새 프로젝트로 새로운 (두 번째) 솔루션을 설정하려고 했습니까? 이 두 번째 솔루션은 솔루션 폴더를 사용하여 모든 파일을 간단히 통합해야합니다. 새로운 솔루션을 사용한 프로젝트의 빌드 시간을보고 놀랄 수도 있습니다.
그러나 두 가지 다른 솔루션을 사용하려면 신중하게 고려해야합니다. 개발자는 실제로 두 번째 솔루션에서 작업을하고 첫 번째 솔루션을 완전히 무시하는 경향이있을 수 있습니다. 70 개 이상의 프로젝트가 포함 된 첫 번째 솔루션은 객체 계층 구조를 관리하는 솔루션이므로 빌드 서버가 모든 단위 테스트를 실행해야하는 솔루션이어야합니다. 따라서 연속 통합 서버는 첫 번째 프로젝트 / 솔루션이어야합니다. 객체 계층을 유지해야합니다.
The second solution with just one project (which will build mucho faster) will than be the project where testing and debugging will be done by all developers. You have to take care of them looking at the buildserver though! If anything breaks it MUST be fixed.
Make sure your references are Project references, and not directly to the DLLs in the library output directories.
Also, have these set to not copy locally except where absolutely necessary (The master EXE project).
I posted this response originally here: https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473 You can find many other helpful hints on that page.
If you are using Visual Studio 2008, you can compile using the /MP flag to build a single project in parallel. I have read that this is also an undocumented feature in Visual Studio 2005, but have never tried myself.
You can build multiple projects in parallel by using the /M flag, but this is usually already set to the number of available cores on the machine, though this only applies to VC++ I believe.
I notice this question is ages old, but the topic is still of interest today. The same problem bit me lately, and the two things that improved build performance the most were (1) use a dedicated (and fast) disk for compiling and (2) use the same outputfolder for all projects, and set CopyLocal to False on project references.
Some additional resources:
- https://stackoverflow.com/questions/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/
Some analysis tools:
tools->options->VC++ project settings -> Build Timing = Yes will tell you build time for every vcproj.
Add /Bt switch to compiler command line to see how much every CPP file took
Use /showIncludes to catch nested includes (header files that include other header files), and see what files could save a lot of IO by using forward declarations.
This will help you optimize compiler performance by eliminating dependencies and performance hogs.
Before spending money to invest in faster hard drives, try building your project entirely on a RAM disk (assuming you have the RAM to spare). You can find various free RAM disk drivers on the net. You won't find any physical drive, including SSDs, that are faster than a RAM disk.
In my case, a project that took 5 minutes to build on a 6-core i7 on a 7200 RPM SATA drive with Incredibuild was reduced by only about 15 seconds by using a RAM disk. Considering the need to recopy to permanent storage and the potential for lost work, 15 seconds is not enough incentive to use a RAM disk and probably not much incentive to spend several hundreds of dollars on a high-RPM or SSD drive.
The small gain may indicate that the build was CPU bound or that Windows file caching was rather effective, but since both tests were done from a state where the files weren't cached, I lean heavily towards CPU-bound compiles.
Depending on the actual code you're compiling your mileage may vary -- so don't hesitate to test.
How big is your build directory after doing a complete build? If you stick with the default setup then every assembly that you build will copy all of the DLLs of its dependencies and its dependencies' dependencies etc. to its bin directory. In my previous job when working with a solution of ~40 projects my colleagues discovered that by far the most expensive part of the build process was copying these assemblies over and over, and that one build could generate gigabytes of copies of the same DLLs over and over again.
Here's some useful advice from Patrick Smacchia, author of NDepend, about what he believes should and shouldn't be separate assemblies:
There are basically two ways you can work around this, and both have drawbacks. One is to reduce the number of assemblies, which is obviously a lot of work. Another is to restructure your build directories so that all your bin folders are consolidated and projects do not copy their dependencies' DLLs - they don't need to because they are all in the same directory already. This dramatically reduces the number of files created and copied during a build, but it can be difficult to set up and can leave you with some difficulty pulling out only the DLLs required by a specific executable for packaging.
Perhaps take some common functions and make some libraries, that way the same sources are not being compiled over and over again for multiple projects.
If you are worried about different versions of DLLs getting mixed up, use static libraries.
Turn off VSS integration. You may not have a choice in using it, but DLLs get "accidentally" renamed all the time...
And definitely check your pre-compiled header settings. Bruce Dawson's guide is a bit old, but still very good - check it out: http://www.cygnus-software.com/papers/precompiledheaders.html
I have a project which has 120 or more exes, libs and dlls and takes a considerable time to build. I use a tree of batch files that call make files from one master batch file. I have had problems with odd things from incremental (or was it temperamental) headers in the past so I avoid them now. I do a full build infrequently, and usually leave it to the end of the day while I go for a walk for an hour (so I can only guess it takes about half an hour). So I understand why that is unworkable for working and testing.
For working and testing I have another set of batch files for each app (or module or library) which also have all the debugging settings in place -- but these still call the same make files. I may switch DEBUG on of off from time to time and also decide on builds or makes or if I want to also build libs that the module may depend on, and so on.
The batch file also copies the completed result into the (or several) test folders. Depending of the settings this completes in several seconds to a minute (as opposed to say half an hour).
I used a different IDE (Zeus) as I like to have control over things like .rc files, and actually prefer to compile from the command line, even though I am using MS compliers.
Happy to post an example of this batch file if anyone is interested.
Disable file system indexing on your source directories (specifically the obj directories if you want your source searchable)
If this is a web app, setting batch build to true can help depending on the scenario.
<compilation defaultLanguage="c#" debug="true" batch="true" >
You can find an overview here: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx
You also may want to check for circular project references. It was an issue for me once.
That is:
Project A references Project B
Project B references Project C
Project C references Project A
One cheaper alternative to Xoreax IB is the use of what I call uber-file builds. It's basically a .cpp file that has
#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"
Then you compile the uber units instead of the individual modules. We've seen compile times from from 10-15 minutes down to 1-2 minutes. You might have to experiemnt with how many #includes per uber file make sense. Depends on the projects. etc. Maybe you include 10 files, maybe 20.
You pay a cost so beware:
- You can't right click a file and say "compile..." as you have to exclude the individual cpp files from the build and include only the uber cpp files
- You have to be careful of static global variable conflicts.
- When you add new modules, you have to keep the uber files up to date
It's kind of a pain, but for a project that is largely static in terms of new modules, the intial pain might be worth it. I've seen this method beat IB in some cases.
If it's a C++ project, then you should be using precompiled headers. This makes a massive difference in compile times. Not sure what cl.exe is really doing (with not using precompiled headers), it seems to be looking for lots of STL headers in all of the wrong places before finally going to the correct location. This adds entire seconds to every single .cpp file being compiled. Not sure if this is a cl.exe bug, or some sort of STL problem in VS2008.
Looking at the machine that you're building on, is it optimally configured?
We just got our build time for our largest C++ enterprise-scale product down from 19 hours to 16 minutes by ensuring the right SATA filter driver was installed.
Subtle.
There's undocumented /MP switch in Visual Studio 2005, see http://lahsiv.net/blog/?p=40, which would enable parallel compilation on file basis rather than project basis. This may speed up compiling of the last project, or, if you compile one project.
When choosing a CPU: L1 cache size seems to have a huge impact on compilation time. Also, it is usually better to have 2 fast cores than 4 slow ones. Visual Studio doesn't use the extra cores very effectively. (I base this on my experience with the C++ compiler, but it is probably also true for the C# one.)
I'm also now convinced there is a problem with VS2008. I'm running it on a dual core Intel laptop with 3G Ram, with anti-virus switched off. Compiling the solution is often quite slick, but if I have been debugging a subsequent recompile will often slow down to a crawl. It is clear from the continuous main disk light that there is a disk I/O bottleneck (you can hear it, too). If I cancel the build and shutdown VS the disk activity stops. Restart VS, reload the solution and then rebuild, and it is much faster. Unitl the next time
My thoughts are that this is a memory paging issue - VS just runs out of memory and the O/S starts page swapping to try to make space but VS is demanding more than page swapping can deliver, so it slows down to a crawl. I can't think of any other explanation.
VS definitely is not a RAD tool, is it?
Does your company happen to use Entrust for their PKI/Encryption solution by any chance? It turns out, we were having abysmal build performance for a fairly large website built in C#, taking 7+ minutes on a Rebuild-All.
My machine is an i7-3770 with 16gb ram and a 512GB SSD, so performance should not have been that bad. I noticed my build times were insanely faster on an older secondary machine building the same codebase. So I fired up ProcMon on both machines, profiled the builds, and compared the results.
Lo and behold, the slow-performing machine had one difference -- a reference to the Entrust.dll in the stacktrace. Using this newly acquired info, I continued to search StackOverflow and found this: MSBUILD (VS2010) very slow on some machines. According to the accepted answer the problem lies in the fact the Entrust handler was processing the .NET certificate checks instead of the native Microsoft handler. Tt is also suggested that Entrust v10 solves this issue that is prevalent in Entrust 9.
I currently have it uninstalled and my build times plummeted to 24 seconds. YYMV with the number of projects you currently are building and may not directly address the scaling issue you were inquiring about. I will post an edit to this response if I can provide a fix without resorting to an uninstallation the software.
It's sure there's a problem with VS2008. Because the only thing I've done it's to install VS2008 for upgrading my project which has been created with VS2005. I've only got 2 projects in my solution. It isn't big. Compilation with VS2005 : 30 secondes Compilation with VS2008 : 5 minutes
Nice suggestions that have helped so far (not saying there aren't other nice suggestions below, if you are having issues, I recommend reading then, just what has helped us)
- New 3GHz laptop - the power of lost utilization works wonders when whinging to management
- Disable Anti Virus during compile
- 'Disconnecting' from VSS (actually the network) during compile - I may get us to remove VS-VSS integration altogether and stick to using the VSS UI
Still not rip-snorting through a compile, but every bit helps.
We are also testing the practice of building new areas of the application in new solutions, importing in the latest dlls as required, them integrating them into the larger solution when we are happy with them.
We may also do them same to existing code by creating temporary solutions that just encapsulate the areas we need to work on, and throwing them away after reintegrating the code. We need to weigh up the time it will take to reintegrate this code against the time we gain by not having Rip Van Winkle like experiences with rapid recompiling during development.
Orion did mention in a comment that generics may have a play also. From my tests there does appear to be a minimal performance hit, but not high enough to sure - compile times can be inconsistent due to disc activity. Due to time limitations, my tests didn't include as many Generics, or as much code, as would appear in live system, so that may accumulate. I wouldn't avoid using generics where they are supposed to be used, just for compile time performance
참고URL : https://stackoverflow.com/questions/55517/very-slow-compile-times-on-visual-studio-2005
'development' 카테고리의 다른 글
| 텍스트 파일의 내용을 자바 스크립트 변수에 어떻게로드합니까? (0) | 2020.06.29 |
|---|---|
| Obj-C에서 Swift 's Enum을 사용할 수 있습니까? (0) | 2020.06.29 |
| 마지막 푸시를 Git으로 롤백하는 방법이 있습니까? (0) | 2020.06.29 |
| 엘릭서에서 문자열을 결합하는 방법? (0) | 2020.06.29 |
| bat 스크립트로 콘솔 출력을 파일로 에코하고 보내려면 어떻게합니까? (0) | 2020.06.29 |