## Re: Interpretation of call-graph data

 Re: Interpretation of call-graph data From: Josef Weidendorfer - 2004-06-04 10:00:33 ```[missed the list] Hi, On Thursday 03 June 2004 14:10, John Levon wrote: > On Thu, Jun 03, 2004 at 11:21:49AM +0200, Josef Weidendorfer wrote: > > > Where in the gprof file format is this kept? > > > > About call arcs? The format has different sections, and one of them holds > > the call count for the call arcs appearing in a program. For the gprof > > algorithm, look at the original gprof paper, e.g. at > > http://docs.freebsd.org/44doc/psd/18.gprof/paper.pdf > > Indeed. Now look at the file format. It does NOT store full backtraces, > but only A>B, B>C, C>D. As the paper explains the static call graph is > used but this is NOT present in the sample file format. Sorry about any misunderstanding here. I never claimed GProf raw data includes full backtraces. This is in fact not needed for the gprof analysis. > In case you missed my point here: there's nothing preventing oprofile > using the same analysis, since we have > > a) the dynamic two-valued call graph data > b) the static call graph (from the binary) The GProf algorithm uses (see section 3 of the paper): - arcs appearing in the static and dynamic call graph, - call counts of arcs (C^r_e), - (self) cost of routines. In OProfile, when you not traverse full backtraces, you only get part of the arcs in the program (your point a). Even if these arcs are available in the static call graph, the algorithm needs the traversal count. The prerequisite for gprof is not met. So I fail to see your point. > In particular, we can and do output in gprof format. Ah, sorry, I missed this. BTW, one problem of gprof is that the format currently only can handle one binary image, making the analysis of code using shared libraries impossible. > There is no requirement for storing full backtraces (at least, not if > you want to bring up gprof, since that doesn't either). For gprof, full backtraces are indeed not needed. But you need the arcs of the full backtraces for gprof to give useful results. But gprof aside, my original point was that I think that backtraces are a useful information for postprocessing tools. I see that its storage is costly (OTOH, you already store the backtraces in the kernel buffer). Cheers, Josef > > regards > john ```