After 17 years of working in games, I've recently just written an article on some tests to improve C++ compilation speed inside MSVC 2015.

I managed to get compile times down from 13.1 to 2.1 seconds and have documented the steps.

Let me know what you think. Happy to answer questions either here or on the blog there.

http://weaseltrongames.blogspot.co.uk/2017/05/compiler-investigations.html

Cheers!

Adrian

www.weaseltron.com
@WeaseltronGames
https://twitter.com/WeaseltronGames
http://weaseltrongames.blogspot.co.uk/

Hi and thanks for the comments.

Yeah I'm used to much longer compile times but it's impractical to recompile so many times on projects where it takes minutes or hours to compile. For this I was most interested in finding the potential impact of various changes. It's true, though that the bottlenecks in a larger codebase will differ to those in a smaller project. I find the link times the most galling on large projects but that's the subject of another post.

Good point about having excluded directories for Defender. I'll run some more tests and update - as obviously not all the files it checks will be in the project directory (.exe, .dlls, registry, whatever else).

I strongly suspect for the reasons you mention and the reasons in the post that #includes in headers make a massive difference in larger code bases. I suspect that one include in the wrong place could massively negatively impact performance though this didn't show up so much in mine.

Precompiled headers - I wanted to just test having the system includes in there. IIRC MSVC won't let you maintain multiple precompiled headers in a single project ... which is just silly.

Code would always be on an SSD for me - it's just been historically on the HDD as compile times of 13s is hardly too much of a chore!

@Zipster: To be clear I didn't see any evidence that I was I/O bound though I'd expect that to make more of a difference on large (game-sized) projects during the linking stage.

My experience is typically with AAA games and I don't see a reason to not have your code on an SSD if you can (perhaps using a junction point to keep the game data where performance often makes less difference). The biggest win for an SSD is with a cold cache which is of course relevant.

IME, larger projects often have very long link times and neither Unity builds and Incredibuild don't help those. On some projects I've compiled nearly just as quick on a many core PC than on a large build farm.

I'll check LOC (when I find a consistent way of doing that). I don't make massive use of complex templates but there's an Array class that gets used extensively.

How many lines of code are you testing this with? Do you use templates?

For reference, my game's hitting around 2mins full rebuild with 150k LOC.

It looks to be around 47k files over 571 files using the trick here: https://yomotherboard.com/how-to-get-total-line-count-in-visual-studio-2013/ to count the lines of code...

I'll add that it's possible to have Defender still running, but prevent it from checking certain folders.

I just updated the article with this. It saves some but not most of the time. On one test the compile time went from 12.2s (base) to 11.7s (saves 0.5s) with the project directory excluded vs 9.7s (saves 1.9s) with it off.

I'd be interested to see which virus checker makes the least difference.