Some doubts about the graph generated by gprof and gprof2dot -


i used gprof2dot generate graph below, visualized program's profiling output.

i have doubts graph:

first, why root of call tree isn't main(), , root bat_read() not appeared in program, declared in .h file.

second, gmatrix c++ class without explicitly destructor, , unreasonable call 2 functions in graph. half of time spending illogic.

third, long function @ bottom of graph, spends 6.94 percentages of time ?

enter image description here

you can read graph in new tab , magnify it, can see clearly.

i magnified image read it.

the function @ bottom wide because has extremely long name, method _m_erase of red-black tree. called half million times galois_w16_region_multiply. size draws attention it, in fact appears on 7% of samples.

if take every block in diagram has no parents, , add inclusive percents, 100%. of indicates gprof's method of propagating time upwards through call graph flaky, thinks things @ top, when in fact couldn't figure out caller was.

you can't tell this. might consider alternatives gprof.

added: gprof puts entry code every function compiled -pg flag. when calls b, code in b tries figure out routine called it, using return address , looking in table of functions. uses increment counter saying how many times called b. if reason cannot figure out correct caller, mistakes see in graph. example, says routines

  ~vector   ~gmatrix   galois_w32_region_multby_2   galois_get_log_table   bat_read 

are @ tops of call chains (have no callers among functions). what's more, thinks main called bat_read.

this typical of gprof.


Comments

Popular posts from this blog

blackberry 10 - how to add multiple markers on the google map just by url? -

php - guestbook returning database data to flash -

delphi - Dynamic file type icon -