5

I'm trying to profile a shared library on GNU/Linux which does real-time audio processing, so performance is important. I run another program which hooks it up to the audio input and output of my system, and profile that with callgrind.

Looking at the results in KCacheGrind, I get great information about what functions are taking up most of my time. However, it won't let me look at the line by line information, and instead says I need to compile it with debugging symbols and run the profiling again.

The program which I am profiling is not compiled with debug symbols, but the library is. And I know this, because interestingly, source code annotations for cachegrind work fine.

When I run callgrind, it says the default is to dump source line information, but it just isn't doing that. Is there some way I could force it to, or figure out what's stopping it?

durron597
  • 31,968
  • 17
  • 99
  • 158
Jeremy Salwen
  • 8,061
  • 5
  • 50
  • 73

2 Answers2

0

Are you using --dump-instr=yes --trace-jump=yes to get the instruction level information?

Douglas Leeder
  • 52,368
  • 9
  • 94
  • 137
0

As you have correctly identified callgrind by default is performing the event count at source code level. Quoting from the man page of callgrind -

--dump-line=<no|yes> [default: yes]

But then during post-processing, you have to provide the path to source files for the callgrind_annotate tool using the --include option for it to generate the annotated source-code with line by line information. Quoting from the man page of callgrind_annotate -

       -I, --include=<dir>
           Add dir to the list of directories to search for source files.

This is the sample command that worked for me -

callgrind_annotate --auto=yes --include=/home/sangeek/source callgrind.out.15078 > callgrind.annotate.txt

Also please note that the source-code level annotated report is placed after the usual file:function summary report in the file. So, you'll have to scroll past those in the report to reach them.

sangeek
  • 11
  • 4