简体   繁体   中英

Mixing debug and release in MSVC?

I got a program that has a quite simple 'load up' function that takes about 30 seconds (3M triangles that goes into std containers). It works perfectly well.

The rest doesn't always (it is not finished) so I debug a lot I make a lot of changes and so on which means restarting quite often.

Is there any secret technique to compile the loader in release (which speeds up everything enormously) and leaving the rest as debug?

ps. I use MSVC 2005

Debug builds tend to be very slow on Visual C++. There are a few reasons for this:

  • the most obvious is that the code is not optimized
  • the memory allocation functions in the debug CRT library perform additional checks to detect heap corruption and other issues, so they are slower.
  • many STL functions perform additional validations and assertions on debug builds, which make use of STL containers very slow

I've had success debugging apps that make heavy use of memory and STL using the following method:

  • use the release build for debugging (yes, this works fine!).
  • configure your release builds to include debugging symbols, this should make the compiler write the .pdb file that the debugger uses
  • only for the files you intend to debug, set the compiler to no optimizations.

Note that the above works great to debug problems in your own logic, but it may not be the best idea if you are debugging memory corruption or other problems, since you are eliminating all the extra debug code that the CRT provides for these types of issues.

I hope this helps!

Mixing debug and release builds tends to go horribly wrong.

But there's no reason why you shouldn't turn on optimisation for some selected source files even in a debug build - and the optimisation should give you the performance improvements.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM