2
votes

I'm doing some number crunching in C++, and I'm seeing a vast difference in CPU % usage when using -Os optimization in my Debug build. I would therefore like to profile my code with optimizations enabled, so that I don't waste time optimizing code that the compiler already optimizes well.

When I try to profile with -Os optimization, I can't get Instruments to symbolicate my code (even when I manually specify the location of my .dSYM file). It won't even show my top-level C++ member functions that are not templated or inlined.

I can get it to symbolicate fine when I specify the default -O0 optimization level.

So, is it even possible to profile with optimizations enabled? If so, then what's the trick to make it work?

I'm using XCode 4.3.3.

1
A comment I have is that generally, as a programmer, you're going to be optimising at a higher level than the compiler, e.g. using the correct data structures, lazy loading or whatever, whereas the compiler is going to be inlining methods, unrolling loops etc. So I don't think you're wasting your time optimising with compiler optimisation turned off, you're not going to be optimising the same kinds of things as the compiler. - Jon Burgess
@JonoB: Consider this scenario (which is close to mine). Before optimization, in my innermost loop, StepA() takes 100ms and StepB() takes 100ms. After optimization, StepA() takes 10ms and StepB() takes 50ms. Without profiling information with optimizations enabled, how am I supposed to know that I should focus my efforts on StepB(). - Emile Cormier
What compiler/xcode version are you using? I often profile with -Os or higher (in a release build). - Jesse Rusak
@EmileCormier I guess you can't really know that. In my experience with profiling, it's often pretty clear where a bottleneck is, compiler optimisations or not, but obviously this isn't always going to be the case. - Jon Burgess

1 Answers

2
votes

Time Profiler did indeed symbolicate when using -Os. The optimizer did it's job so well, that my C++ DSP code got inlined and speeded up to the point where the profiler would not sample any of it in the short amount of time that I let it run. All I could see in the call tree were system calls.

When I tried running the profiler for longer, the profiler caught a few blips of my DSP code. It only showed my top-level DSP function called by some NSOperationQueue handler. The rest underneath seemed to be all inlined.

I got more useful results when I compiled with -O2. More of my DSP subroutines were left intact (instead of being inlined), so I was better able to gauge where my DSP algorithm was spending its time. But all that is moot, because now I can see that the app is spending vastly more time in housekeeping system calls than in my DSP code.