Very Slow Compile Times on Visual Studio 2005

Very slow compile times on Visual Studio 2005

The Chromium.org team listed several options for accelerating the build (at this point about half-way down the page):

In decreasing order of speedup:

• Install Microsoft hotfix 935225.
• Install Microsoft hotfix 947315.
• Use a true multicore processor (ie. an Intel Core Duo 2; not a Pentium 4 HT).
• Use 3 parallel builds. In Visual Studio 2005, you will find the option in Tools > Options... > Projects and Solutions > Build and Run > maximum number of parallel project builds.
• Disable your anti-virus software for .ilk, .pdb, .cc, .h files and only check for viruses on modify. Disable scanning the directory where your sources reside. Don't do anything stupid.
• Store and build the Chromium code on a second hard drive. It won't really speed up the build but at least your computer will stay responsive when you do gclient sync or a build.
• Defragment your hard drive regularly.
• Disable virtual memory.

Speed up compilation in Visual Studio 2005

Besides pre-compiling headers, there are number of other things that could be slowing you down:

• Virus checking software - can have a nasty impact on builds. If you have a virus checker running try to turn it off and see what sort of improvement you get.
• Low RAM - Not enough RAM will cause many more disc reads and slow you down. cont ->
• Slow HDD - You have to write to disc regardless and a slow drive, like those present in many laptops and lower-end systems, will kill your builds. You can get a faster drive, a RAID array or SSD
• Slow processor(s)... of course.
• Unlikely, but: Check and see if your projects are referencing network shares. Having to pull files across the network with each build would a big slowdown.

EDIT Few more thoughts:

• If your solution contains a large number of projects you could consider creating other "Sub" solutions that contain only the projects that you're actively working on. This possibility depends on how interrelated your projects are.
• The project builds can have pre and post build event commands associated with them. Check the properties of your projects to see if there are any costly build events specified.

Very slow compile times on Visual Studio 2005

The Chromium.org team listed several options for accelerating the build (at this point about half-way down the page):

In decreasing order of speedup:

• Install Microsoft hotfix 935225.
• Install Microsoft hotfix 947315.
• Use a true multicore processor (ie. an Intel Core Duo 2; not a Pentium 4 HT).
• Use 3 parallel builds. In Visual Studio 2005, you will find the option in Tools > Options... > Projects and Solutions > Build and Run > maximum number of parallel project builds.
• Disable your anti-virus software for .ilk, .pdb, .cc, .h files and only check for viruses on modify. Disable scanning the directory where your sources reside. Don't do anything stupid.
• Store and build the Chromium code on a second hard drive. It won't really speed up the build but at least your computer will stay responsive when you do gclient sync or a build.
• Defragment your hard drive regularly.
• Disable virtual memory.

Slow compile times when Visual Studio 2012 is open

I've figured this out. I believe it was the result of some malware. I diagnosed the problem with the following steps.

1. Download ProcMon (http://technet.microsoft.com/en-gb/sysinternals/bb896645.aspx)
2. Add a filter to ProcMon on process name: csc.exe
3. I then ran a compile from the command line, with visual studio open. It took around 10 seconds, way too long! Looking at the output in the ProcMon window, I noticed what appeared to be csc.exe pausing for 5 secs, once towards the beginning of the trace, and once towards the end. See the following screens:

Start:

End:

It appeared that a RegCloseKey to HKLM\SOFTWARE\Wow6432Node\5c28f8fbc6fe942 was causing csc.exe to wait for 5 seconds, twice.

RegKey:

I then decided to rename this entry (added _old to the end), I then recompiled....BINGO, it compiled in less than 30ms!

After studying the entries contained in this key and some googleing it turned out that this reg key was the result of some malware. I used the following guide to remove thte malware and now the problem is completely solved.

http://www.explosiveknowledge.net/main/2012/08/19/browsemngr/

Please be aware that the guide above doesn't contain the correct reg entries, I think the virus must have been tweaked at somepoint, I couldn't find the reg entries mentioned in the guide but simply deleted the ones I'd found.

Please note that the 5c28f8fbc6fe942 part of the reg key seems to be randomly generated. If you have this problem is might be different but the values contain within will still talk about "Browser Manager".

Hope this helps someone!

How do I speed up visual studio with a large number of projects?

There are a whole bunch of suggestions in this question: Very slow compile times on Visual Studio. A combination of a few of these will definitely help to some degree

Does having more projects in your visual studio increase compile time?

The compiler takes each class through references. The bottom layer (no internal project references) has to be compiled first, then the layers that reference other internal projects, and so on. Therefore, yes, the compile time will be slightly increased due to the fact that the compiler has to sort the references and create multiple binaries.

On the other hand, most large projects SHOULD be separated into multiple projects and namespaces for ease of readability and navigation. It really depends on what you're doing, but you could potantially put 1000 classes in a single file, or multiple files, or multiple files in multiple projects. The amount of time (minimal) saved in the compile time won't compare to the time wasted looking for stuff in a poorly laid out solution.

With a solution of 2 projects with 5 classes, the compile time will be milliseconds different from a single project of 10 classes. The linking and referencing is the only real increase you'll see, and that is minimal.

EDIT: On another note, if you have a project large enough that you're noticing a real difference in compile time, you should probably be considering implementing some sort of continuous integration (see: http://en.wikipedia.org/wiki/Continuous_integration) environment, which will keep a current build ready for you, as well as letting you know if something's broken.

---

Related Topics