5

Is the Release Build always faster than the Debug build (because, the release build is optimizing a lot)?, even if I write the fastest performance code possible?

Or is it possible to write C++ code (using debug) which is as fast as the Release Build?

I'm just curious if my code Is too slow, because I notice a respectable difference, when I do performance tests.

Burkhard
  • 14,596
  • 22
  • 87
  • 108
jeromintus
  • 367
  • 1
  • 5
  • 14
  • 2
    When profiling you should always run with optimizations enabled, because aside from extremely simple code or inline assembly, often different instructions will be generated (or even, in the case of libraries, different C++ code will be compiled, for instance in MSVCs implementation of the STL). – Thomas Russell Aug 29 '14 at 20:07
  • I also notice a differnce, for simple programms with small method calls(gettet/setter) - in a loop of course - without any other liaberies, even when I use inline etc. to get the a good performance – jeromintus Aug 29 '14 at 20:14
  • That is likely because the compiler often can (and will) perform various performance enhancing operations when in release mode with optimization enabled (for instance auto-vectorization/auto-parallelization, loop-unrolling, etc.), and using `inline` doesn't guarantee that the compiler will inline it. – Thomas Russell Aug 29 '14 at 20:16
  • @Shaktal: vectorization and parallelization you could write yourself. – Ben Voigt Aug 29 '14 at 20:22
  • 2
    In general, Release builds will be faster than Debug builds. But if you're curious whether it's *possible* to write code that is faster in Debug, the answer is yes. It would be tricky though - one example could be to construct code such that the unoptimized assembly loads, as a side-effect, warm some cache lines that are later accessed. – MooseBoys Aug 29 '14 at 20:29
  • 1
    @Shaktal: You say when profiling you should always run with optimizations enabled. I think it depends on whether you are simply measuring performance or actively trying to find performance bugs. Those are different objectives. A performance bug is where the program is wasting clock time doing something unnecessary. You don't find it by wishing the program were fast. You find it by [*debugging what it is spending time on*](http://stackoverflow.com/a/378024/23771). The optimizer cannot remove things one may be doing that are unnecessary, but it can make them hard to find. – Mike Dunlavey Aug 29 '14 at 21:13
  • 1
    The "Release build" and "Debug build" are what you make them. They are just **different sets of compiler flags**, named like this to give the impression that one should be used for debugging and the other for releases. Typically (although it depends a lot on the application domain), you do *not* want this, because you want to debug what you give to your customers, and vice versa. The fact that the Visual Studio IDE adds two such configurations to all new projects by default does not mean it's a natural law of C++ software development... – Christian Hackl Aug 29 '14 at 21:18

3 Answers3

16

A good choice of algorithm definitely will make a big difference in speed of a debug build, but debug builds will never be as fast. It's because the optimizer schedules registers completely differently, trying to make code run fast, while the debug compiler tries to preserve values of temporary variables so you can read them from the debugger.

Since you probably have a lot more variables than CPU registers, this means the debug compiler will emit instructions to copy those values to RAM. While in a release build, if the value isn't used again, the optimizer will just throw it away.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
0

In general, it depends.

Some release builds may not be different than debug builds.

Also depends on the configuration difference between a debug and a release build. If the only difference is symbolic information in the debug release, then they will have the same performance.

At my shop, we are releasing debug software. The executable goes into Flash without any symbols.

Thomas Matthews
  • 56,849
  • 17
  • 98
  • 154
0

If you have data structure validation in your code, it could make debug a lot slower than release.

On the other hand, if your app is of the type that spends most of its time calling system routines such as I/O, memory allocation, semaphore waits, etc. then release won't be much faster than debug.

On yet another hand, if your program has functions using a lot of self time, those will be faster in a release build.

Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • why are functions with a lot of self time faster with the release build? – jeromintus Aug 29 '14 at 22:02
  • @Sleicreider: Code only benefits from optimization for the fraction of time that the program counter is actually in it, and that's what self time is. If 99% of the time the program counter is in memory allocation, math library, or waiting for I/O, then even if the optimizer speeds up your code infinitely, it can't save more than 1% overall. – Mike Dunlavey Aug 30 '14 at 00:06
  • in my case i used simple method calls like: `string& GetText() { return text: }` – jeromintus Aug 30 '14 at 10:42