Jump to content

  • Log In with Google      Sign In   
  • Create Account

VC++ Express, Debug is vastly slower than Release


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 martinis_shaken   Members   -  Reputation: 145

Like
0Likes
Like

Posted 26 January 2012 - 06:55 AM

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!



Sponsor:

#2 Evil Steve   Members   -  Reputation: 1983

Like
3Likes
Like

Posted 26 January 2012 - 07:24 AM

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.

Steve Macpherson
Systems Programmer

Rockstar North


#3 AllEightUp   Moderators   -  Reputation: 4216

Like
0Likes
Like

Posted 26 January 2012 - 07:26 AM

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.

#4 Álvaro   Crossbones+   -  Reputation: 13363

Like
0Likes
Like

Posted 26 January 2012 - 08:24 AM

I use g++, so perhaps this won't help you. What I often do is compile most of the code optimized but disable optimizations for the module or modules on which I am working. Since I am usually not working on the most performance-critical parts of the program, this results in decent performance and I can still debug the parts I need. It should be possible to create intermediate configurations between "Debug" and "Release" in VC++ to achieve something similar.

#5 Marvel Magnum   Members   -  Reputation: 333

Like
0Likes
Like

Posted 26 January 2012 - 08:25 AM

Have you tried using the profiler ? It might help prove the point that Evil Steve & All EightUp has mentioned.

#6 NightCreature83   Crossbones+   -  Reputation: 2832

Like
0Likes
Like

Posted 26 January 2012 - 08:55 AM

I believe that by default the VSC++ compiler has the option set to compile and link for speed when release is ticked and all of these optimisations are completely turned off in debug.
Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#7 martinis_shaken   Members   -  Reputation: 145

Like
0Likes
Like

Posted 26 January 2012 - 09:15 AM

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.


Thank you for this. It is definitely STL heavy so that would make sense. I have gone ahead and switched my working mode to Release and will code in that for now. If I encounter bugs, I will tab over to Debug mode and go from there.


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.


I have combed it a bit with timers as Marvel suggested, but not too diligently. As it is, I think you're right that I may need to code in Release mode unless I encounter errors (I'll keep off the O/2 flags though). I'd hate to abandon the vectors just yet. Changing some settings in the compiler's Debug configuration to match the Release ones, such as in-lining functions as Steve mentioned definitely sped things up considerably. I had no idea that Debug was so much slower.



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!

#8 Marvel Magnum   Members   -  Reputation: 333

Like
0Likes
Like

Posted 26 January 2012 - 09:49 AM

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!

You are most welcome ! Posted Image

#9 NightCreature83   Crossbones+   -  Reputation: 2832

Like
0Likes
Like

Posted 30 January 2012 - 05:22 AM


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.


Thank you for this. It is definitely STL heavy so that would make sense. I have gone ahead and switched my working mode to Release and will code in that for now. If I encounter bugs, I will tab over to Debug mode and go from there.


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.


I have combed it a bit with timers as Marvel suggested, but not too diligently. As it is, I think you're right that I may need to code in Release mode unless I encounter errors (I'll keep off the O/2 flags though). I'd hate to abandon the vectors just yet. Changing some settings in the compiler's Debug configuration to match the Release ones, such as in-lining functions as Steve mentioned definitely sped things up considerably. I had no idea that Debug was so much slower.



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!


Thats why creating a development configuration might be a good idea, this is an in between release and debug build and you could only turn on what you need in this. This would give you some of the speed of a release build and the ease of a debug build on the parts that you are interested.
Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS