MacResearch

Those are very expensive comments =)

I don't have much experience with Instruments, so I'm drawing a blank there. For Shark, start by making sure you have the latest version installed. Download the latest version of the "CHUD Tools" to update Shark (and make sure to run CHUD Remover before installing).

If the problem persists, or even if it doesn't, please file a bug report.

Shark (and I presume instruments) do not always mark the correct line where the instruction taking the time is located in the source. You _may_ have to shift by one or two lines down. You can check the assembly (side-by-side) to align the percentages with the proper lines in the code, as well.

As Stephen said, file a bug report. But in the meantime if you are not certain which lines to look at, just shift down one (maybe two lines). It will still get you in the general vicinity of where you are spending time.

Dave

I am also seeing this (time attached to comments) and other strange behavior when using high optimization levels (-O2, -O3). For instance, I also noticed identical function calls that take very different amount of time, or "hotspots" at operations that should take (almost) no time.

My code (C++) is heavily templated and uses lots of inline functions, and I think this kind of behavior is to be expected for such a code. If you take a look at the corresponding assembler code, you'll see that one line of source code is very often scattered over a large part of of the assembler code. The optimizations performed by the compiler sometimes involve quite heavy transformation of your source code, so it gets very difficult, if not impossible, to relate time spend in a bunch of assembler instructions back to your original code.

Unfortunately I can confirm this is a long-standing problem. I seem to remember hearing hints that this is much improved under clang/llvm, but I can't confirm first hand until C++ support is improved and I can migrate my code to that compiler system.

I find Shark's source code time profile to be often entirely useless, but I recommend trying to understand the assembly code time profile. This is not actually too hard for maths-heavy inner loops, and can often give you the detailed information you need to understand what is holding the code back.

One very specific issue that you *can* work around (radar bug# 4723147) occurs if you open two traces for the same program, each containing different versions of the same embedded source files. This completely throws Shark and it will report utter rubbish. The workaround is simply to open one such trace, quit and relaunch shark, and then open the second trace.

I did not work too much with osx profiling tools to profile OpenFOAM. For Shark, I also start by making sure you have the latest version installed. I find and download the latest version of the "CHUD Tools" to update Shark. Do not forget to run CHUD Remover before installing.If the problem persists, or even if it doesn't, I file a bug report.There are also audio tutorials on this topic at web mp3 sources . It might be useful for those who are concrened about OpenFOAM.

Haven't tried it out, maybe you want to have a look at the developer preview of Xcode 4. IIRC it also comes with new profiling tools.