Personally, I haven’t found STL or Boost to be useful for game runtime in a console environment. On a PC I might consider it, but I would probably choose not to because of their effect on build times like you’re experiencing.

Thanks for the quick reply – I found the article soon after my post – sorry I should have done a more extensive search!

I tried to get the analysis perl script working, but came across a few problems, perlmod seems to get confused easily (much like myself ) I had a number of unmatched brackets errors, I did get it running against a particular project, but it reported a lot of useless headers which were actually quite useful (essential to compile) .

I’m not sure what I am doing wrong, but I’ll hopefully have a chance to look at it after Christmas. I havent used doxygen before – i was creating the doxyfile using the win32 wizard thingy.

I am using quite a lot of STL and Boost, I am also using Ogre.

I’ll have to have a major look at ways to reduce it, it can’t continue at this speed, I am getting distracted when I am compiling as you mention in the article, it makes it really hard to keep the flow.

Thanks again!
All the best,
Ash

My best advice on compile times is in this article: http://gamesfromwithin.com/?p=8

Basically it comes down to:
- Use include guards
- Make the first include of each cpp file its corresponding .h file
- Keep what you have in a header file to a minimum (forward declare instead of include, etc)
- Keep your logical dependencies to a minimum (don’t include windows.h unless you absolutely have to for example).

Precompiled headers can be OK, but I’m not a huge fan of them. Maybe for some really heavy headers like windows or Havok if you use them in most of your code.

The times you’re quoting sound pretty high. Are you using STL? That’s a time sink for sure!

For my game I have currently around 60000 lines including some tests, My build time for just modifying a single .cpp is around 30 secs. Around 5 seconds for the library in question, 10-15 to link the test runner and 10-15 for the game to link.

It is getting to be very frustrating – 2 secs would be a dream . I am using CxxTest and Visual Studio 2005 on a Q6600 Quadcore with 3 gig of ram and a reasonably fast HD – I am also using Precompiled headers.

Do you have any general tips on getting the compile time down? I’ve always had the feeling that it was slow, but I now realise its massively slow!

Thanks for your help
All the best,
Ash

as you wrote in your article that you got a performance improvment by not initilizing the memory.

“Even though the constructor was simply initializing its members to zero, that was causing a significant slow down when so many objects were created.”

That is the way that I learned my whole life to initialize the member variables by a class and even a struct. What is Lint saying about this?

Regards,
Eddie

It’s interesting that you only initialise Havok once for all tests – are you not worried about potential side effects between different tests being run? I’ve had numerous problems with tests giving incorrect results because a previous test has gone haywire in some way. Theres nothing worse than people complaining that your test is failing only to discover that it’s actually fine but someone else’s test is corrupting memory beforehand. Have you avoided any problems like this so far?

I now spawn a new process for each test so that they can’t interfere, but this adds about half a second to every test (for an 18Mb executable). This isn’t as bad as it seems really, since usually I’m only running a tiny subset, and there’s a command line option to run in a single process for when you want to run everything quickly (which takes about a second for my ~150 tests).

Could you please tell me, what mocking framework are you using? mockpp? Or something else? Are you doing mocking at all?

http://xkcd.com/303/

Having said that, I’m starting to look for a better solution. I’d like a mock framework (or something) not so much to avoid writing the mock, but to avoid having to change the architecture. Right now when we mock a class, we need to create an interface, whether one was needed or not. Even worse, when we mock a static, non-member function, we need to do all sorts of weird things (either make it a class, or create a function pointer somewhere, or something).

Even though I usually favor really, really simple solutions, our friend Rory Driscoll has started writing about his mocking framework, MockItNow, so that’s something I’d like to check out soon.

With a runtime that is roughly a million lines of code that generates a 20 meg executable (significantly larger with symbols), our link times alone are closer to 5 minutes. I’d love to get that pulled down, but I don’t know what a reasonable minimum is to target given our scale.

Sadly, incremental builds haven’t worked for us in a long time. I don’t recall the cause – I think it had something to do with all of our iteration code existing in libraries.

Lots of people have been asking about it, so I was planning on writing a followup post to this one with the exact code size, number of tests, C vs. C#, and all that fun stuff.

On the other hand I have to ask… one million lines of code???? That sounds enormous, even for a full-blown retail game. Is that for FEAR? What’s the breakdown between libraries and game code? Does that include script code?

Anyway, I’ll try to write that other post tonight and that might spark some discussions and people sharing their code sizes.