2

I'm debugging a large C++ project (Linux environment) and one binary appears to be taking more time to run than I expect. How can I see a breakdown of how much time each function call in each source file takes, so I can find the problem(s)?

CaptainSegFault
  • 82
  • 1
  • 10
kjakeb
  • 6,810
  • 5
  • 20
  • 34

3 Answers3

4

There's another way to find the problem(s) than by getting a breakdown of function times.

Run it under a debugger, and manually interrupt it several times, and each time examine the call stack. If you look at each level of the call stack that's in your code, you can see exactly why that moment in time is being spent.

Suppose you have a speed problem that, when fixed, will save some fraction of time, like 30%. That means each stack sample that you examine has at least a 30% chance of happening during the problem. So, turning it around, if you see it doing something that could be eliminated, and you see it on more than one sample, you've found your problem! (or at least one of them) **

That's the random-pausing technique. It will find any problem that timers will, and problems that they won't.

** You might have to think about it a bit. If you see it doing something on a single sample, that doesn't mean much. Even if the code is only doing a thousand completely different things, none of them taking significant time, it has to stop somewhere. But if you see it doing something, and you see it on more than one sample, and you haven't taken a lot of samples, the probability that you would hit the same insignificant thing twice is very very small. So it is far more likely that its probability is significant. In fact, a reasonable guess of its probability is the number of samples in which you saw it, divided by the total number of samples.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • This is a good suggestion. But may not be the answer to get function timings. – Satish Chalasani Jul 23 '15 at 14:28
  • @Satish: That happens a lot. He wants to "find the problem(s)", and he thinks timing is the way to do it. It's an [*XY problem.*](http://xyproblem.info/) – Mike Dunlavey Jul 23 '15 at 14:41
  • I was crucified earlier when I gave suggestions like you had given here in other questions. Just being careful now... – Satish Chalasani Jul 23 '15 at 14:43
  • @Satish: Ever heard "Behold the turtle. He makes progress only when he sticks his neck out."? It's not easy to go against entrenched misunderstandings, but if you can show you're right, you're doing a service. – Mike Dunlavey Jul 23 '15 at 14:47
3
#include <iostream> 
#include <ctime>

int main() {
    std::clock_t start = std::clock();

    //code here

    double duration = ( std::clock() - start ) / (double) CLOCKS_PER_SEC;
    std::cout << duration << std::endl;
}
ignQ1744a
  • 31
  • 2
0

You can create your own timer class. At the starting of each block call method to reset the timer variable to zero and get the timer at the end of the code block. You can do this in various blocks of the code. Once you had identified the code block that takes more time, you can have internal timers too.. If you want try a standard tool than I would recommend to use gprof. http://www.thegeekstuff.com/2012/08/gprof-tutorial/

Satish Chalasani
  • 167
  • 7
  • 1
    *gprof* is venerable, but it is being asked to do things it never promised and is not good at, like finding speedups. [*Look here.*](http://archive.is/9r927) – Mike Dunlavey Jul 23 '15 at 14:24