1

So, I have some code that I am trying to speed up. Some relevant notes about this program:

1) I've commented out all the I/O

2) I've turned off multi-threading for these purposes export OMP_NUM_THREADS=1

3) No recursion

Now, I run the code and gprof tells me that it spends 87% of its time in getGamma

 %   cumulative   self              self     total
 time   seconds   seconds    calls  us/call  us/call  name
 87.49     20.69    20.69  3125353     6.62     6.62  Alkali::getGamma(double, double)

(This is the very first line of the profile, so I think I am reading this correctly. gprof2dot produces and image with getGamma in bright red so I'm probably right.)

The problem is that getGamma is basically a stub:

double Alkali::getGamma(double tau, double laser_power) {
  double gamma = (1.0 / tau);
  return gamma;
}

And when I grep on getGamma I only get the definition and one call in a setup routine. Yep, adding a print statement confirms that this trivial function is only called once.

So what is fooling gprof? Among other compiler flags, I'm using -O3. Let me know if you need any more info and thanks in advance.

fenkerbb
  • 795
  • 2
  • 7
  • 18
  • it is called `3125353` according to report, not once. – Jarod42 Aug 05 '15 at 01:02
  • Lots of people say "only profile optimized code". I, for one, disagree. But what's more, *gprof* does not stand up to critical scrutiny. There are very few posts where people actually understand *gprof* output. Check the comments on [*this post*](http://stackoverflow.com/q/31794197/23771). – Mike Dunlavey Aug 05 '15 at 01:56
  • @Jarod42: It cannot possibly be called that many times. I add a print statement and I see the print statement exactly once, yet `gprof` still reports 3 million calls. This agrees with `grep`. – fenkerbb Aug 05 '15 at 16:32
  • 1
    @fenkerbb Did you ever get to the bottom of this? I was reading up on the limitations of profiling and I'm intrigued by your question. – Casperrw Oct 07 '16 at 13:58

0 Answers0