4

For my project, the release version (compiled with the -O2 flag) has higher performance than the debug version (compiled with the -g -O0 flag).

So I have to use the release version.

However, in the production environment, the release program sometimes produces core dumps.

I then use gdb xxx core to debug the core dump file, but there is not enough information for me.

I don't care about the size of the program or any other file. I want the best performance and the most detailed possible debug info.

What should I do?

DinoStray
  • 696
  • 1
  • 6
  • 20
  • 2
    [Debug symbols really don't affect performance](https://stackoverflow.com/questions/39222698/does-compiling-with-g-in-itself-degrade-performance/39223245). They'll increase the binary size, but performance shouldn't be affected. Compile with optimizations and debug symbols on. – NathanOliver Jun 18 '19 at 12:32
  • 1
    I'd recommend the [compiler documentation](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html). – chris Jun 18 '19 at 12:33
  • **You can still use `-g` with optimization options -- it doesn't affect performance of the code!** – Jonathan Wakely Jun 20 '19 at 10:23

4 Answers4

5

-g does not change the code generated. It only adds debug information. Therefore it should not affect performance.

You should investigate why you are seeing a performance difference - that may reveal some useful information.

The optimisation settings are the ones that affect performance. If you need to have them on, then try the -Og optimisation setting. It will enable optimisations that do not interfere with debugging.

Finally, Production is generally not a great place to debug. Your other environments should be designed to reproduce all bugs that can occur on Production. The goal is to ensure that you never encounter a new bug on Production. Very difficult in practice of course, but consider spending less time on getting debug to work on Production and more time on getting your other environments to match so closely that you can identify (perhaps by comparing logs) and then reproduce the bug there. As a benefit, you'll catch more bugs before they reach Production.

Heath Raftery
  • 3,643
  • 17
  • 34
2

You should compile with -g -O2, and (if you're sure it's necessary), strip the debug symbols to a separate symbols file. I can't remember the exact steps, as I usually let dh-strip do that for me when building packages, but the idea is that the symbols don't consume memory in the program's process - you load them into the debugger.

Toby Speight
  • 27,591
  • 48
  • 66
  • 103
0

I wanna the best performance

What should I do?

Enable optimisation.

I wanna ... the most detailed debug info.

What should I do?

Disable optimisation (or if your compiler supports such option: enable only optimisation that doesn't interfere with debugging; -Og in case of g++) and enable debug symbols.

As you may notice, these requirements are in a conflict.

A decent compromise for debugging a dump from a release is to enable both optimisation, and enable debug info for the build, especially considering ...

I don't care the size of the program or any other file.

which is what the debug info mostly affect. There is no need to avoid enabling debug info unless you care about the size of the program.

Community
  • 1
  • 1
eerorika
  • 232,697
  • 12
  • 197
  • 326
  • 1
    What's wrong with "enable optimization *and* debug symbols"? – Employed Russian Jun 19 '19 at 02:44
  • _"Enable optimisation and disable debug symbols."_ [citation needed] – Jonathan Wakely Jun 20 '19 at 10:22
  • @JonathanWakely That is what [CMake](https://github.com/Kitware/CMake/blob/master/Modules/Compiler/GNU.cmake) does in RELASE mode. They also have a RELWITHDEBINFO, which matches with my suggestion to enable both optimisation, and debug symbols. – eerorika Jun 20 '19 at 10:33
  • That doesn't make it right. Omitting debug info doesn't improve performance. – Jonathan Wakely Jun 20 '19 at 10:38
  • @JonathanWakely As far as I know, debug info uses storage space. Since DinoStray doesn't care about the program size, my suggestion of enabling debug symbols is appropriate for them, in my opinion. I've also read comments about debug info wasting space in read-ahead cache. If you have documentation that contradicts this, I'd like to see it. – eerorika Jun 20 '19 at 10:49
  • Storage space doesn't affect performance, neither does putting data in the readahead cache that can be replaced by other data as needed. You said debug info should be disabled for best performance, but have failed to back that claim up. – Jonathan Wakely Jun 20 '19 at 11:13
  • @JonathanWakely If the program is transferred across network before execution, that transfer time can be a significant part of the entire process. – eerorika Jun 20 '19 at 11:31
  • You're grasping at straws now. OP clearly said "I don't care about the size of the program or any other file." Debug info does not affect performance of the code. Period. Your answer says "disable debug symbols" to get the best performance. That's wrong, especially in the context of "I don't care about the size of the program or any other file." – Jonathan Wakely Jun 20 '19 at 11:46
  • @JonathanWakely I wrote my answer to not only cover OP's case, where they don't care about size of the program, but also other cases where it does matter. We cannot assume that OP is the only person to read this page. I've edited the answer in order to not distract from the point. – eerorika Jun 20 '19 at 12:28
-1

You also want to set -fno-omit-frame-pointer so that you know where you are while debugging. It will slow down execution, as there is one less usable register, but debugging is a compromise between performance and information (and sometimes you need these to find out that the compiler assumed things in release mode!).

CMake uses by default -O3 for release and -O2 -g for release with debug info (useful for debugging and profiling), so you have a good start, just add the frame pointer to have a better context.

And yes, debugging in production? Scary. Find a reproducer.

Matthieu Brucher
  • 21,634
  • 7
  • 38
  • 62
  • "so that you know where you are" -- on most architectures debugger can tell you where you are perfectly well *without* `-fno-omit-frame-pointer`. – Employed Russian Jun 19 '19 at 02:44
  • @EmployedRussian No, with the amount of inlining gcc can do in optimized mode, it may tell you you are in function A when you are actually in function B (have you actually used a debugger on an optimized build?). – Matthieu Brucher Jun 19 '19 at 09:17
  • 1
    I do debugging of optimized code *all the time*. At least on `x86_64`, GDB is perfectly capable of telling you about inlined functions for optimized builds with debug info. – Employed Russian Jun 19 '19 at 14:28