The game engine I am working with is too slow in the debug build and is impossible to debug the game. One of the things I would like is for the compiler to inline small functions (especially in Vector/Matrix and container classes). This may or may not speed up the game in debug build. Before profiling heavily and trying to figure out bottlenecks I thought I would try this first as I would have to do minimal work and the results may be promising.
So, is there a way to get the Visual C++ compiler to inline functions in debug builds?
Project options -> C/C++ -> Optimization -> Inline Function Expansion. Turn this to /Ob2. Do this in your Debug configuration.
In Release, inline function expansion is implied by other optimization settings, so even though by default all configurations say "Default" for the setting, the behavior is indeed different.
I believe Debug builds should have inline expansion behavior the same as release; there's really no reason not to.
http://msdn.microsoft.com/en-us/library/47238hez.aspx
You're confusing two compiler options. /O influences optimization, including inlining. /ZI creates the PDB file for debugging. They can be set independently.
It may be useful to clone the "Debug" configuration, though, and create a "Debug-optimized" configuration with both /O1 and /ZI.
You might try __forceinline. Be sure to read about debug builds on that page (turn off the /Ob0 option).
My suspicion is that this will not change the performance very much. Another thing to try if you haven't already is just to add symbols to a release build. It works fairly well for debugging a lot of issues.
DEBUG is defined by Visual Studio when a project is compiled in Debug mode so:
#ifdef DEBUG
inline void fn() {
#else
void fn() {
#endif
Related
I am recently working with Eigen library with visual C++ to solve a very large sparse linear system. Program works really fast in Release mode, but in Debug mode it takes hours to solve. I traced the timing, the program takes long time in "solve" function of Eigen. I want to build the project in debug mode as I need to debug a lot. Now is there a way not to generate debug information for Eigen portion? Or is there any other workaround for this problem?
#MichaelWalz's answer is great, but I would like to add (as I have outlined in my comment to your question) that I strongly recommend not using Eigen in Debug mode.
Eigen is a highly efficient, yet very usable matrix library. It achieves its efficiency through a lot of “template magic”, using many layers of abstraction, and relies on the compiler's optimization stages to produce highly efficient code.
Debug mode usually implies that the compiler creates debug symbols, but also disables optimization. In GCC/clang, it is usually equivalent to -O0 -g; I believe in Visual Studio it corresponds to /O0 /DEBUG.
I recommend building all code that uses Eigen in a “release-with-debug-info” mode instead (what CMake calls CMAKE_BUILD_TYPE=RelWithDebInfo). This means that you allow the compiler to optimize, while still generating debug symbols. In GCC/clang, this is usually equivalent to -O2 -g; I believe in Visual Studio it corresponds to /O2 /DEBUG. Personally I have had very good experiences like this; IMHO it is only in very rare circumstances that you actually need to disable optimization completely.
You can disable debug information and enable code optimisation per file.
In the Solution Explorer right click on the file that contains the Eigen function, then chose Properties.
In the dialog that appears, choose the C/C++->Optimisation and chose the same options you have in Release mode.
Then choose C/C++->General and under "Debug Information Format" choose "None". But the presence of debug information has probably no influence on execution speed.
MSVC defines _DEBUG in debug mode, gcc defines NDEBUG in release mode. What macro can I use in clang to detect whether the code is being compiled for release or debug?
If you look at the project settings of your IDE, you will see that those macros are actually manually defined there, they are not automatically defined by the compiler. In fact, there is no way for the compiler to actually know if it's building a "debug" or "release", it just builds depending on the flags provided to it by the user (or IDE).
You have to make your own macros and define them manually, just like the IDE does for you when creating the projects.
Compilers don't define those macros. Your IDE/Makefile/<insert build system here> does. This doesn't depend on the compiler, but on the environment/build helper program you use.
The convention is to define the DEBUG macro in debug mode and the NDEBUG macro in release mode.
You can use the __OPTIMIZE__ flag to determine if optimization is taking place. That generally means it is not a debug build since optimizations often rearrange the code sequence. Trying to step through optimized code can be confusing.
This probably is what those most interested in this question really are attempting to figure out.
There is no such thing as a debug mode in a command line compiler. That is a IDE thing: it just sets up some options to be sent to the compiler.
If you use clang from the command line, you can use whatever you want. The same is true for gcc, so if with gcc you use NDEBUG you can use just the same.
From here: http://google-glog.googlecode.com/svn/trunk/doc/glog.html
Debug Mode Support
Special "debug mode" logging macros only have an effect in debug mode and are compiled away to nothing for non-debug mode compiles.
What does "debug mode" mean w.r.t C++ program?
Can we say a program is in debug mode when we are using GDB on it?
There's three sides to "debug mode".
A lot of libraries (including standard libraries) will insert debug-helping code (array bounds checking, invariant assertions, that sort of thing) when they are compiled in debug mode. They remove these checks in production/non-debug mode to help performance.
Compilers have debug switches. The set debug macros that the libraries use to detect whether you are compiling for debug or not, and insert debug symbols in the produced binaries. This helps debuggers make the link between the binary code that is running and the source code that generated it.
Running an program in a debugger is a "runtime debug mode". You can run an executable in a debugger whether or not it was built for debugging. You'll get more information with a debug build.
All three of these "debug modes" are independent. You could (usually) compile library debug checks in a production build by setting the appropriate macros/defines manually without asking the compiler to output debug symbols.
None of this is specific to C++ (or C). A lot of other languages have these concepts.
"Debug mode" can refer to a lot of things, but in this case it refers to compiling without the NDEBUG macro defined. From the page that you linked to (emphasis mine):
The DFATAL severity logs a FATAL error in debug mode (i.e., there is no NDEBUG macro defined), but avoids halting the program in production by automatically reducing the severity to ERROR.
C++ programs (like C) usually have different build configurations based on preprocessor macros, which can be passed from the command line.
The canonical debug mode flag is the macro NDEBUG, which if defined means you are not in debug mode. (It could be more clearly named PRODUCTION, but sadly it's named in terms of what it's not.)
NDEBUG is standard, and ancient. It is used by the <cassert> header, which is known as <assert.h> in C. Its official function is to make the assert macro into a no-op, but it also usually affects the C++ standard library in terms of checking bounds and requirements.
For example, g++ -DNDEBUG myProg.cpp -o myProg should compile without runtime features related to debugging.
Note that this is different from producing symbolic support for the debugger, which is controlled with -g on GCC, or other flags for other platforms.
today i found out that the compiled static library i'm working on is much larger in Release mode than in Debug. I found it very surprising, since most of the time the exact opposite happens (as far as i can tell).
The size in debug mode is slightly over 3 MB (its a fairly large project), but in release it goes up to 6,5 MB. Can someone tell me what could be the reason for this? I'm using the usual Visual Studio (2008) settings for a static library project, changed almost nothing in the build configuration settings. In release, i'm using /O2 and "Favor size or speed" is set to "Neither". Could the /O2 ("Maximize speed") cause the final .lib to be so much larger than the debug version with all the debugging info in it?
EDIT:
Additional info:
Debug:
- whole program optimization: No
- enable function level linking: No
Release:
- whole program optimization: Enable link-time code generation
- enable function level linking: Yes
The difference is specifically because of link-time code generation. Read the chapter Link-Time Code Generation in Compilers - What Every Programmer Should Know About Compiler Optimizations on MSDN - it basically says that with LTCG turned on the compiler produces much more data that is packed into the static library so that the linker can use that extra data for generating better machine code while actually linking the executable file.
Since you have LTCG off in Debug configuration the produced library is noticeably smaller since it doesn't have that extra data.
PS:
Original Link (not working at 11/09/2015)
The optimization could be the issue here, notably automatically created inline functions will be bigger but faster in release than debug.
Personally I've never seen a release PDB be larger than a debug PDB. Same deal for LIBs.
I need to profile an application compiled with intel's compiler via VC++.
I'm using VTune to profile my code.
My understanding is that in release mode I won't have the debug information
that is necessary for the profiler to profile my code while in debug mode, the result
of the profiling will not be pertinent.
What should I do ? Is it possible to add debug info in release mode?
How can I set this mode?
If so, will I still benefit from all the optimization (inlining etc.)?
You should certainly profile with optimisations enabled (compiler option /O3). /Zi is the Intel compiler switch (on Windows) to enabled debugging information.
Because of the optimisations, some functions may be missing from the debugging information due to inlining, but VTune will cope with that.
You can generate program database files (PDB) even in release target. Go to project properties, Linker/Debugging and check the option "Generate Program Database File". It is usually something like "$(TargetDir)$(TargetName).pdb". Now, it depends whether VTune knows how to interpret PDB files...
Function inlining and interprocess optimizations will make your profile hard to interpret. That is why it is a good idea to profile in both debug and release modes. If release mode only shows function foo using 80% of the program time, you can use the debug profile to see that function bar, which was inlined into foo, is using 60% of foo's time.