• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
martinis_shaken

VC++ Express, Debug is vastly slower than Release

8 posts in this topic

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!

0

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.
0

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.
0

Share this post


Link to post
Share on other sites
Have you tried using the profiler ? It might help prove the point that [b]Evil Steve[/b] & [b]All EightUp [/b]has mentioned.
0

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.
0

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.
[/quote]

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.


[quote name='AllEightUp' timestamp='1327584379' post='4906404']
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.

[/quote]

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!
0

Share this post


Link to post
Share on other sites
[quote name='martinis_shaken' timestamp='1327590938' post='4906433']
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]
You are most welcome ! [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
0

Share this post


Link to post
Share on other sites
[quote name='martinis_shaken' timestamp='1327590938' post='4906433']
[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.
[/quote]

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.


[quote name='AllEightUp' timestamp='1327584379' post='4906404']
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.

[/quote]

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.
0

Share this post


Link to post
Share on other sites

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
Sign in to follow this  
Followers 0