2

So I want to distribute my gcc application with backtrace logging for critical errors. Yet it is quite performance critical application so I wonder if -g -rdynamic gcc flags do slow down execution (especially if they do allot)? Also would like to give my users maximum performance so I do compile with optimization flags like "-flto" and "-mtune" and that makes me wonder if flags would conflict and inside baacktrace would be madness?

Community
  • 1
  • 1
myWallJSON
  • 9,110
  • 22
  • 78
  • 149
  • With optimizations on, your stacktrace will not be garbage, but due to inlining and some other optimizations, it's possible not to get all stack frames you would without optimization. – arne Dec 19 '13 at 09:46
  • 2
    If you can't tell (when you have your code, and are running it on your own machine), what makes you think that a bunch of random people on the internet with no idea what your code does will know? – Steve Jessop Dec 19 '13 at 09:47
  • @SteveJessop: general gcc knowledge / Linux production experience. – myWallJSON Dec 19 '13 at 09:51
  • Keeping debug symbols in production code doesn't reduce performance, it only adds bloat. I was shipping such code as well, in order to get a meaningfull error report from clients. – Devolus Dec 19 '13 at 09:51

2 Answers2

2

Although introducing debug symbols does not affect performance by itself, your application still end up far behind in terms of possible performance. What I mean by that is that it would be bad idea to use -g and -O3 simultaneously, in general. Therefore, if your application is performance critical, but at the same time severely needs to keep good level of debugging, then it would be reasonable to find some balance between these two. In the latest versions of GCC, we are provided with -Og flag:

Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience.

I think it would be good idea to test your application with this flag, to see whether the performance is indeed better than bare -g, but the debugging stays intact.

Once again, do not neglect reading official GCC documentation. LTO is relatively new feature in GCC, and, as a result, some of its parts are still experimental and are not meant for production. For example, this is the direct extract:

Link-time optimization does not work well with generation of debugging information. Combining -flto with -g is currently experimental and expected to produce wrong results.

Not so long ago I had mixed experience with LTO. Sometimes it works well, sometimes the project doesn't even compile, not to mention that there could also be subtle runtime issues. Summarizing all of it, I would not recommend using LTO, especially in your situation.

NOTE: Performance gain from LTO usually varies from 0% to 3%, and it heavily depends on the underlying application. Without profiling, you cannot tell whether it is even reasonable to employ LTO for your situation as it might deliver more troubles than benefits.

Flags like -march and -mtune usually do optimizations on a very low level - instruction level for the target processor architecture. Thus, I wouldn't expect them to interfere with debugging. Nevertheless, you are welcomed to test this yourself with your application.

Alexander Shukaev
  • 16,674
  • 8
  • 70
  • 85
  • 1
    I don't think this answers OP's question at all. – R.. GitHub STOP HELPING ICE Dec 19 '13 at 10:10
  • @R.: OP's goals: 1) deliver good performance to end users; 2) keep reasonable debugging; 3) learn about pitfalls with mixing certain flags. All of these are addressed in my answer. – Alexander Shukaev Dec 19 '13 at 10:22
  • Well OP accepted it so I guess I'm wrong that it's not useful to OP. However nothing in the question was about debugging options; OP just wanted backtraces, and there's certainly no reason to sacrifice `-O3` for this. Personally I almost never switch optimizations off for debugging purposes, but whether it's useful to do so depends a lot on the types of debugging tools you use and the types of bugs you find yourself dealing with. – R.. GitHub STOP HELPING ICE Dec 19 '13 at 17:57
1

-g has no impact whatsoever on performance. -rdynamic will increase the size of the dynamic symbol table in the main executable, which might slow down dynamic linking. My best guess is that the slow-down will be very small but possibly measurable (nonzero) with precise measurement/profiling tools.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711