• entries
    121
  • comments
    278
  • views
    156112

SlimDX Compile Times

Sign in to follow this  

183 views

This post was taken from Ventspace.

When I was doing the November 08 release of SlimDX, I had to do a lot of builds to get it right. As a result, I was keenly aware of compile times, which sucked to be quite frank. On my main development workstation, a full rebuild of Release x86 was around ten minutes. Debug was a bit quicker, but still around eight minutes. I don't have a very powerful machine at home, but when I tested the fairly powerful system at work, it still didn't go terribly fast. It turns out that you really don't have to accept the long builds that naive project layout creates.

I've just now done a rebuild of Release x86 in under five minutes. A few relatively simple steps have cut it in half; Debug builds are almost down to a third. The changes, although tedious, were relatively simple and mechanical, and didn't really involve any increased risks for bugs. That's a very good thing with large changes, especially when trying to attack problems that are arguably not THAT important.

The first change was to roll out precompiled headers across the library. Our PCH file is extremely simple; it just includes all of the system and DirectX headers, and a handful of library headers. These headers are fairly massive though, and we saw benefits from the PCH basically immediately. I'd avoided PCH at the beginning because I've always found it to be a pain in the ass, but the trade off was worth it. It helps that the headers in there don't really change.

The other trick was a bit more subtle. See, Visual C++ compiles all of its input .cpp files to .obj files in the project intermediate directory. However, it does not preserve any input directory structure into that folder. So in SlimDX, we had direct3d9/Device.cpp, direct3d10/Device.cpp, directinput/Device.cpp, and so on. In the intermediate directory, these became Device1.obj, Device2.obj, Device3.obj, etc. That's not compiler-automatic, either -- it has to be configured in the project build settings per file. The IDE is capable of doing that step automatically, but when it comes to actually doing the build, the compiler process has to be spun up separately for each individual file. Compared to the amount of compilation required for any given C++ file, this is a fairly substantial cost, especially when multiplied by a hundred or so.

Once we renamed the files so they no longer conflicted in a flat directory structure, we got the current build timings. In fact, it takes almost as much time to link as it does to compile. (I'm sad that linking is still a single threaded operation.) Not bad, all in all.
Sign in to follow this  


5 Comments


Recommended Comments

Why would I do that? I WANT whole program optimization in my release builds.

Share this comment


Link to comment
[lol]

whilst I didn't bother timing it, a full debug x64 build on my machine was maybe a minute or two at most. No impression on my end that it was slower than I'd expect. But I do have a reasonably powerful machine - quad core @ 3.1ghz with 4GB RAM...

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now