From: Wallace, R. <Ric...@sp...> - 2003-09-09 02:49:19
|
Hello, So far oprofile is the most useful profiling tool that I have come = across. It is easy to use and has little overhead. It works great on = the massively complex, massively multithreaded application that I have = been assigned to "eliminate bottlenecks" on. I do have some questions. I am using oprofile 0.6 compiled from source = on a RH 7.2, dual 1GHz P3 system. I'm using CPU_CLK_UNHALTED with a = count value of 6000. Oprofile works great, like I said above. When a run of the app is done = I do a dump and save the profile and start to do my analysis. Here's = where I run into questions. It seems that oprofile, through the = opreport utility, can only provide very high-level analysis of the = system by showing what process ate the most resources or it can give a = very low-level analysis showing the exact symbols that performed the = most work. That's great and all, but I need to do some kind of trace = back from the low-level to find where (function wise) in my code all the = time is being spent. Most of the symbols opreport shows are C++ = template operations. But I have no way of back tracking to see where = those operations are being used so that I might optimize them. I thought I might annotate the source code to see if I could find the = hotspots that way, but I can't seem to get opannotate to do what I want. = I've been running it with the following command: opannotate event:CPU_CLK_UNHALTED session:blah --exclude-dependent = --source --output-dir=3D~/annotated /path/to/binary This runs for a really long time eating up a lot of CPU, but when it = gets done, instead of a bunch of annotated C++ files in ~/annotated I = get nothing but header files. Those are annotated, but they don't = provide the detail I was expecting. Any ideas? Thanks Richard Wallace |
From: John L. <le...@mo...> - 2003-09-11 15:26:17
|
On Mon, Sep 08, 2003 at 04:46:25PM -0700, Wallace, Richard wrote: > Oprofile works great, like I said above. When a run of the app is > done I do a dump and save the profile and start to do my analysis. > Here's where I run into questions. It seems that oprofile, through > I thought I might annotate the source code to see if I could find the > hotspots that way, but I can't seem to get opannotate to do what I > want. I've been running it with the following command: > opannotate event:CPU_CLK_UNHALTED session:blah --exclude-dependent --source --output-dir=~/annotated /path/to/binary The command looks OK to me. > This runs for a really long time eating up a lot of CPU, but when it > gets done, instead of a bunch of annotated C++ files in ~/annotated I > get nothing but header files. Those are annotated, but they don't > provide the detail I was expecting. How many samples total for the application (not its libraries) ? What does the opreport -l output for it look like ? Is it all compiled with -g ? Remember that samples in inlined functions generally go to the source of the inline function - thus if you're doing lots of stuff with the STL, most of the samples are likely to end up in headers. But it's unusual that you don't get *any* samples in the app sources itself... regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over. |