Hello,

I am using Microsoft Visual C++ 2010 Express, and I may have a configuration issue. My question is: why is my debug build so slow compared to my release build? There are a lot of different settings for release vs config, but both are out of the box configurations. I haven't changed anything.

--------

I have just built a quadtree to use for collision detection in my game, using Netbeans 7.0 and 7.1 in a Linux (Ubuntu 11.04) environment. The tree can insert 1,200,000 objects per second on my older, mediocre laptop. The code uses nothing specific to the OS, and the only library outside the standard STL that is used is boost 1.47's foreach command for vector element iteration.

The code consists of recursive calls, and at its simplest test run (just inserting, not clearing or removing objects, or querying neighbors) it only uses a loop of the nodes, a bounds check, and a vector to dynamically insert objects, else recursive call to go deeper in the tree. My initial incarnation of the quadtree involved template meta-programming, void* vectors, etc., but I was programming on my desktop and it didn't seem fast enough. Now I'm kicking myself because I think it could have gone much, much faster if I had only had the correct configuration.



When I decided to run it on my new i3 laptop and my powerful i7 desktop, I expected amazing performance, even a ten-fold increase.

I created a new project in VC++ (empty). Added the source and header files. Added the boost directory to my include path. This is an "out of the box" installation of VC++. I hit build, all was fine, and then it ran. VERY SLOWLY. At even a tenth the speed on a machine that is vastly more capable than my core 2 duo laptop from 2006. I was amazed and perplexed and worried all at once.

I went to new laptop, same problem. I tried installing netbeans (wouldn't work, needs mingw).

On my new laptop, I switched from Debug mode to Release and built it (no optimization flags). Then I cd'd to the Release directory and ran the executable. The program hauled ass churning through 1,200,000 object insertions and 120 tree clears (100,000 objects per frame, 120 fps) about twice as quickly as my old laptop. I turned on O/2 flags, it went even faster.
I went back and ran Debug mode (F5 and without debugging ctrl+f5) and it was still slow. I cd'd to Debug directory and ran Test.exe, STILL slow as can be.

In short: Release mode hauls ass, as it should, yet Debug mode crawls. How can I fix? short of copying all my release config options over to debug?

-----------


Thank you all for your help. I am a frequent visitor (though first time poster) of gamedev forums, and I know this is the place to go for all my game programming needs, as gamedev has helped me solve a good number of debacles!

STL code in particular is usually very slow in debug builds, due to none of it getting inlined. Try stepping into some of the STL code and you'll see that simply inserting an item to a tree probably makes about 30-50 function calls - all of which will be inlined in Release, but none will be in Debug. I'm not too surprised that debug runs 10 times slower than release if you're doing a lot of STL-work.

You could try enabling inlining in debug builds, but that might make debugging in a debug build more eratic.

This is unfortunately a problem which has no direct answers. Debug "is" going to be slower and usually by a factor of 2 at minimum, that is the nature of things. But, if it is more on the order of 4+ times slower, then it is likely that you are running into various items which simply require release builds to maintain any form of decent speed. You mention STL and Boost, both of these items will be very slow in debug due to how they work and are coded, so if you rely on those items a lot, that could be your answer and a little judicious replacement of some of that could be all you need. Of course don't "assume" anything though, before you go further I would find/build a decent high performance timer and start inserting it into the code and seeing exactly which parts are really slow. I.e. is insert slow? add more timers and figure out which "part" is slow before changing any of the code.

Always, always start by narrowing the performance problems down as far as possible. It can be a pain but in general it will save you considerable work and pain in the future.

Thank you all for your replies, I really appreciate it! Gamedev is by far the best forum I've seen, and I look forward to contributing to it!