@Ihoujin: When you run the compiler the standard way, it does NOT make much of an effort to make your code run quicker (e.g. by noticing that a value you just computed will be needed again soon and keeping it on hand, avoiding a trip to memory. There are many optimizations, see the like below). It simply tries to make the compiler run quickly and accurately. Depending on the code, you can get dramatic improvements with -O2 or -O3 flags to g++. For instance, I noticed that stretching images from my camera in kstars' fitsviewer goes from about 0.5s - 1.0s / image to something like 0.15s/image. I've been looking at the speed of the fitsviewer computations, and those things get much faster with optimization. Of course, code that runs fast anyway, or waits for cameras or the UI won't be affected much. I believe it is standard practice to release optimized code, however, see Rob's point below. Here's a link to the g++ page on its optimizer and what it might try improve: gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Rob: Debug vs execution speed is always a tradeoff. However (a) you can still have all the logs you've had before, and (b) you don't have to strip away the symbol tables, they can mostly still be there and still be used with optimized code. it's just that it's possible that the compiler, depending on its options, will change the order of certain operations, if that doesn't effect the end result but allows for quicker code. I believe that any commercial code you currently use is optimized. I think that for the most part it won't affect debugging you do for other users. For debugging on your own system, sure you can compile with debug flags while developing and debugging if you prefer. The main gotcha is that it is possible that the optimized code, which let's say is optimized correctly but is a little bit different than the non-optimzed code, can expose (or hide) bugs. That is, say you have a memory error (you overwrite some pointers in memory). The debug and optimize versions may react differently in one version than the other, so errors you see in optimized code may not show up in non-optimized code, or vica versa. However, I'd say this is relatively rare and worth the price paid for getting much quicker overall performance. Try it!