Some doubts about the graph generated by gprof and gprof2dot

Question

I used gprof2dot to generate the graph below, which visualized my program's profiling output.

I have some doubts about the graph:

First, why the root of the call tree isn't main(), and the root Bat_Read() even not appeared in my program, but is declared in the .h file.

Second, GMatrix is a C++ class without explicitly destructor, and it is unreasonable for it to call the two functions in the graph. Almost half of time spending is also illogic.

Third, What is the long function at the bottom of the graph, which spends 6.94 percentages of time ?

You can read the graph in a new tab and magnify it, so you can see it clearly.

Answer 1

I just magnified the image so I could read it.

The function at the bottom is very wide only because it has an extremely long name, but it is only a method _M_Erase of a red-black tree. It is called half a million times from galois_w16_region_multiply. Its size draws your attention to it, but in fact it only appears on about 7% of samples.

If you take every block in the diagram that has no parents, and add up their inclusive percents, you get 100%. All of this indicates that gprof's method of propagating time upwards through the call graph is flaky, so it thinks things are at the top, when in fact it just couldn't figure out who the caller was.

You can't tell much from this. You might consider alternatives to gprof.

ADDED: Gprof puts some entry code into every function compiled with the -pg flag. So when A calls B, the code in B tries to figure out what routine called it, by using the return address and looking it up in a table of functions. It uses that to increment a counter saying how many times A called B. If for some reason it cannot figure out the correct caller, you get mistakes like you see in this graph. For example, it says that routines

  ~vector
  ~GMatrix
  galois_w32_region_multby_2
  galois_get_log_table
  Bat_Read

are at the tops of call chains (have no callers among your functions). What's more, it thinks that main was called by Bat_Read.

This is typical of gprof.