Release Build

For best performance, set the compiler to perform a release build, which leaves out extra debug information. This option is in Build->Set Active Configuration.... Although it is generally assumed that commercial software will be done as a release build, many students are not aware of the option and its effects.
A debug build may link with special debug libraries, and generate different machine code than a release build would. It will include code to help a debugger map machine code to programming language text. It will not perform optimizations that would break a simple mapping from one line of programming language to one section of binary machine code. It may allocate more memory than is requested for objects and buffers to give some padding to protect from buffer overflows. At the same time, the debugger is doing extra checking for pointer errors, buffer overflows, stack overflows, and other such conditions, and uses the extra debug information compiled in to be able to tell where in the code text the error occurred. It is also common to use debugging output or checking, such as the ASSERT() or TRACE() macros, which are only defined and included in a debug build. Such debug macros are often included in standard libraries that your code will link with, even if you don't use them explicitly.
Release builds, on the other hand, are stripped down and optimized for speed, size, or some combination. The compiler may even do such unexpected things as change the order of execution, or omit sections of code, so long as the resulting machine code has the same output. Optimizing for speed may inline small functions to avoid the overhead of a function call at the cost of larger code, while optimizing for size may do the opposite.
While it may look like you could improve software performance by trying to cram all the functionality you can into one line, saving steps and writing more compact code, a good compiler makes that pointless by optimizing the binary code in a similar fashion. The debug build will in fact be smaller, faster binary code if you cram more into a line, since the compiler tries to maintain the mapping from one line of your code to one section of binary machine code. But a compact programming style gives no advantage in a release build, while hampering debugging and making your code harder to follow. As shown above, a programmer can improve performance by changing slightly the details of an algorithm. It is important to distinguish between the sorts of optimizations a compiler can do, and the kind of optimizations only the programmer can do.
Testing 3000 50,000 element arrays of random integers, with all processes on one node using the fastest implementation of merge discussed in the previous section, the release build ran 65% faster than the debug build.