std::vector Debug to release.?
Author
I starte using vector because list was killing my render speed. Now that I use vector, If im in debug I get 63 fps. If I move to release I get 560 fps. Under list, I got 63 in both release and debug. So a HUGE increase. Question is, How can I tell the compiler to use the optimizations in debug for the vector? or can I? thanks much,
Brad
Optimsations shrink code, they spot patterns, simplify, & break code down to it's most simple & direct methods to achieve the effect.
Debug must be able to step through command @ a time. This would not be possible (or @ the least incredible difficult to do or even make logical sense of) if the code had be crunched down in this manner.
Debug must be able to step through command @ a time. This would not be possible (or @ the least incredible difficult to do or even make logical sense of) if the code had be crunched down in this manner.
Author
Ahh very nice thanks, ill check itup on msdn.. anything special I should know that I wont find in the documentation? like what to be careful of? what results I might find good/bad? Thanks much!
--Also, what do others do to get around this? I now am at a 63fps for debug, and a 605fps for a release... This means its gunna kill me if I hafta do this everywhere for debug... Other people do differnet things to get around it?
Brad
--Also, what do others do to get around this? I now am at a 63fps for debug, and a 605fps for a release... This means its gunna kill me if I hafta do this everywhere for debug... Other people do differnet things to get around it?
Brad
Do you really need to optimize your debug code? Debug code is supposed to be slow and allow you to catch errors (E.g. vector probably has a load of assert()s to catch out of range indices).
You could compile some code into a DLL, and link to the release version of the DLL, but that really depends on how your code is structured.
You could compile some code into a DLL, and link to the release version of the DLL, but that really depends on how your code is structured.
You can debug release code, too. Go into the project preferences, and make sure that debug format is "Project Database" and make sure that the linker generates a debug project database file. Then set breakpoints, and run, and debug, in release mode.
Note that the display of local variables may be wrong at times, because in release mode, a local variable may have been eliminated, factored, or re-used for something else. However, it's still useful to be able to step through release mode code (even more so in Disassembly mode).
Note that the display of local variables may be wrong at times, because in release mode, a local variable may have been eliminated, factored, or re-used for something else. However, it's still useful to be able to step through release mode code (even more so in Disassembly mode).
Author
Yea that sounds like the option im looking for. Well I like running debug because of the options it presents. Only problem is, it becomes unrealistic to debug a game once you start introducing large terrains with alot of vectors and lists. physics is still going, yet your frame rate hits the lowest possible speeds, I couldnt imagine trying to debug my physics once I start introducing it more into the game. For those reasons, it seems more likely to find a way now around it than in the future trying to output my physics to a output file and reading thousands and thousands of lines... Maybe im missing something huge here... I prolly am, but I just dont know enough on debuging release... Thanks very much guys, the info is a huge help!
Brad
Brad
I'm not sure what you mean by "debug is supposed to be slow" but I can't think of a case where that should be true.
Can you elaborate on that?? It just sounds plain worng.
Cheers
Chris
Can you elaborate on that?? It just sounds plain worng.
Cheers
Chris
Quote:Original post by chollida1Yeah, thats not really what I meant. What I meant was that debug code is usually slow. Functions don't get inlined, a different version of new and delete are used, and assert()s are evaluated to name a few things. Its just not very surprising that theres a large speed difference between debug and release modes.
I'm not sure what you mean by "debug is supposed to be slow" but I can't think of a case where that should be true.
Can you elaborate on that?? It just sounds plain worng.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
