Jump to content
  • Advertisement
Sign in to follow this  
martinis_shaken

VC++ Express, Debug is vastly slower than Release

This topic is 2511 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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 ! smile.png

Share this post


Link to post
Share on other sites

[quote name='Evil Steve' timestamp='1327584299' post='4906403']
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!
[/quote]

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!