Code Build Optimisation Part 3

So we’ve all done it. You’re coding away and you want to call say, a math function from your templated utility class that lives in your header. So you #include its header in your header, everything works allowing you to move on. It’s a common pattern that many engineering projects are purely feature/result driven; write the code, debug the code, check in and you’re done… next task. Rinse and repeat this pattern for a few months/years across many engineers and you inevitably find that your include structure is heavy & costly. But it all works right? Who cares that it takes 5x longer to compile now. If you care, read on.

Once you get to this stage it is often very difficult to figure out what is going on. Depending on the age of your code base you can often be looking at an include tree 4-5 levels deep (sometimes far worse) and involving 1000′s of files. How do you retroactively figure out where to direct your attention? Hopefully I can help you there.

I should note that the basic method here was written by one of Bungies Senior Engineers

An Example Analysis from Our Engine