1

I am attempting to use to profile a program that I have written, and am receiving unintelligible results. Most of the function names are coming in like _abfcd96687bed377dcecdf193c89698. I beleive that they are coming from a third party library that I am linking against, which I don't have source code for, so I can't recompile it for profiling.

I would like to understand where these functions are coming from, as one of them accounts for 17% of my running time, and I would like to see if I can reduce the number of calls to that as yet unknown function.

Degustaf
  • 2,655
  • 2
  • 16
  • 27
  • Don't expect gprof to answer that question for you. [*Here's what some people do.*](http://stackoverflow.com/a/378024/23771) – Mike Dunlavey Feb 13 '15 at 01:06
  • @MikeDunlavey While investigating this, I found that answer of yours, which I found very interesting. – Degustaf Feb 13 '15 at 13:52
  • @MikeDunlavey When I actually attempted this, my first interrupted placed me in the function in question that takes up 17% of my running time. Unfortunately my debugger only gave me about 3 levels of the call stack (possibly because that was all that was available in that thread). I stepped through to find what function it was being called from, and in the time I was willing to spend (about 5 minutes), it did not leave that function. – Degustaf Feb 13 '15 at 14:20
  • Did you try to see the stack (command "bt")? That should show you the whole reason why you're spending the time, so maybe you can find a better way to accomplish the same thing. In my experience, it's a rare program that can't be sped up. – Mike Dunlavey Feb 13 '15 at 17:08
  • @MikeDunlavey I did use the backtrace functionality in my debugger (DDD). It appears to not be able to cross thread boundries. – Degustaf Feb 13 '15 at 18:10
  • I use GDB, and you can say "thread n" to put it in whatever thread you want, then say "bt". Maybe DDD has something similar? – Mike Dunlavey Feb 14 '15 at 14:06

1 Answers1

0

I was able to determine that the functions in question were part of the third party library using .

The raw callgrind.out file contains a listing of the functions in the program. Included in this is what functions are called as a part of the running of each function.

Using this, I was able to trace up from the functions in question until I reached a function that is part of the library API.

As for the goal of optimization, the API function that is eating up most of my run time (>75%) cannot be called fewer times. This is making it difficult (although not impossible) to spot other hotspots.

Degustaf
  • 2,655
  • 2
  • 16
  • 27