1

I've heard people say it does not, but I thought it better to ask.

Craig
  • 413
  • 7
  • 16

1 Answers1

-1

What happens when you try it? Time some code that you're concerned about, recompile with -g, and time the new code.

It's not going to be any faster having all that debugging stuff in it, but that doesn't mean it will be slower. Most importantly, that doesn't mean it will be slower in code that you care about. If you have a program that runs in 30 seconds without -g and 31 seconds with it, do you care?

First rule of Optimization Club is "do not optimize". Second rule is "do not optimize without measuring".

Andy Lester
  • 91,102
  • 13
  • 100
  • 152
  • 4
    Thanks for taking the time to make that witty Fight Club quip, but it sounds like a long way of saying you don't really know the answer to the question. What I was hoping for was some type of insight into what structural effect -g has on the generated executable. For example, VS code is much slower when debug builds are used due to (for example) range checking on iterators. I was wanting to learn what the analogous situation was in gcc. – Craig Dec 21 '12 at 05:18
  • If you were looking for "insight into what structural effect -g has on the generated executable", then why didn't you ask that? – Andy Lester Dec 21 '12 at 05:56
  • 2
    Here's something I found by searching "what debug information does gcc put in the executable": http://stackoverflow.com/questions/89603/how-does-the-debugging-option-g-change-the-binary-executable – Andy Lester Dec 21 '12 at 06:07
  • Cool, thanks, that's what I was looking for, I did try searching but my terminology was slightly different. – Craig Dec 21 '12 at 07:35
  • Glad you like it. Perhaps your sarcastic dig at me wasn't necessary after all. – Andy Lester Dec 21 '12 at 14:07