gprof.texi

基于4个mips核的noc设计

@node Callers, Subroutines, Primary, Call Graph
@subsection Lines for a Function's Callers

A function's entry has a line for each function it was called by.
These lines' fields correspond to the fields of the primary line, but
their meanings are different because of the difference in context.

For reference, we repeat two lines from the entry for the function
@code{report}, the primary line and one caller-line preceding it, together
with the heading line that shows the names of the fields:

@smallexample
index  % time    self  children called     name
@dots{}
                0.00    0.05       1/1           main [2]
[3]    100.0    0.00    0.05       1         report [3]
@end smallexample

Here are the meanings of the fields in the caller-line for @code{report}
called from @code{main}:

@table @code
@item self
An estimate of the amount of time spent in @code{report} itself when it was
called from @code{main}.

@item children
An estimate of the amount of time spent in subroutines of @code{report}
when @code{report} was called from @code{main}.

The sum of the @code{self} and @code{children} fields is an estimate
of the amount of time spent within calls to @code{report} from @code{main}.

@item called
Two numbers: the number of times @code{report} was called from @code{main},
followed by the total number of non-recursive calls to @code{report} from
all its callers.

@item name and index number
The name of the caller of @code{report} to which this line applies,
followed by the caller's index number.

Not all functions have entries in the call graph; some
options to @code{gprof} request the omission of certain functions.
When a caller has no entry of its own, it still has caller-lines
in the entries of the functions it calls.

If the caller is part of a recursion cycle, the cycle number is
printed between the name and the index number.
@end table

If the identity of the callers of a function cannot be determined, a
dummy caller-line is printed which has @samp{<spontaneous>} as the
``caller's name'' and all other fields blank.  This can happen for
signal handlers.
@c What if some calls have determinable callers' names but not all?
@c FIXME - still relevant?

@node Subroutines, Cycles, Callers, Call Graph
@subsection Lines for a Function's Subroutines

A function's entry has a line for each of its subroutines---in other
words, a line for each other function that it called.  These lines'
fields correspond to the fields of the primary line, but their meanings
are different because of the difference in context.

For reference, we repeat two lines from the entry for the function
@code{main}, the primary line and a line for a subroutine, together
with the heading line that shows the names of the fields:

@smallexample
index  % time    self  children called     name
@dots{}
[2]    100.0    0.00    0.05       1         main [2]
                0.00    0.05       1/1           report [3]
@end smallexample

Here are the meanings of the fields in the subroutine-line for @code{main}
calling @code{report}:

@table @code
@item self
An estimate of the amount of time spent directly within @code{report}
when @code{report} was called from @code{main}.

@item children
An estimate of the amount of time spent in subroutines of @code{report}
when @code{report} was called from @code{main}.

The sum of the @code{self} and @code{children} fields is an estimate
of the total time spent in calls to @code{report} from @code{main}.

@item called
Two numbers, the number of calls to @code{report} from @code{main}
followed by the total number of non-recursive calls to @code{report}.
This ratio is used to determine how much of @code{report}'s @code{self}
and @code{children} time gets credited to @code{main}.
@xref{Assumptions}.

@item name
The name of the subroutine of @code{main} to which this line applies,
followed by the subroutine's index number.

If the caller is part of a recursion cycle, the cycle number is
printed between the name and the index number.
@end table

@node Cycles,, Subroutines, Call Graph
@subsection How Mutually Recursive Functions Are Described
@cindex cycle
@cindex recursion cycle

The graph may be complicated by the presence of @dfn{cycles of
recursion} in the call graph.  A cycle exists if a function calls
another function that (directly or indirectly) calls (or appears to
call) the original function.  For example: if @code{a} calls @code{b},
and @code{b} calls @code{a}, then @code{a} and @code{b} form a cycle.

Whenever there are call paths both ways between a pair of functions, they
belong to the same cycle.  If @code{a} and @code{b} call each other and
@code{b} and @code{c} call each other, all three make one cycle.  Note that
even if @code{b} only calls @code{a} if it was not called from @code{a},
@code{gprof} cannot determine this, so @code{a} and @code{b} are still
considered a cycle.

The cycles are numbered with consecutive integers.  When a function
belongs to a cycle, each time the function name appears in the call graph
it is followed by @samp{<cycle @var{number}>}.

The reason cycles matter is that they make the time values in the call
graph paradoxical.  The ``time spent in children'' of @code{a} should
include the time spent in its subroutine @code{b} and in @code{b}'s
subroutines---but one of @code{b}'s subroutines is @code{a}!  How much of
@code{a}'s time should be included in the children of @code{a}, when
@code{a} is indirectly recursive?

The way @code{gprof} resolves this paradox is by creating a single entry
for the cycle as a whole.  The primary line of this entry describes the
total time spent directly in the functions of the cycle.  The
``subroutines'' of the cycle are the individual functions of the cycle, and
all other functions that were called directly by them.  The ``callers'' of
the cycle are the functions, outside the cycle, that called functions in
the cycle.

Here is an example portion of a call graph which shows a cycle containing
functions @code{a} and @code{b}.  The cycle was entered by a call to
@code{a} from @code{main}; both @code{a} and @code{b} called @code{c}.

@smallexample
index  % time    self  children called     name
----------------------------------------
                 1.77        0    1/1        main [2]
[3]     91.71    1.77        0    1+5    <cycle 1 as a whole> [3]
                 1.02        0    3          b <cycle 1> [4]
                 0.75        0    2          a <cycle 1> [5]
----------------------------------------
                                  3          a <cycle 1> [5]
[4]     52.85    1.02        0    0      b <cycle 1> [4]
                                  2          a <cycle 1> [5]
                    0        0    3/6        c [6]
----------------------------------------
                 1.77        0    1/1        main [2]
                                  2          b <cycle 1> [4]
[5]     38.86    0.75        0    1      a <cycle 1> [5]
                                  3          b <cycle 1> [4]
                    0        0    3/6        c [6]
----------------------------------------
@end smallexample

@noindent
(The entire call graph for this program contains in addition an entry for
@code{main}, which calls @code{a}, and an entry for @code{c}, with callers
@code{a} and @code{b}.)

@smallexample
index  % time    self  children called     name
                                             <spontaneous>
[1]    100.00       0     1.93    0      start [1]
                 0.16     1.77    1/1        main [2]
----------------------------------------
                 0.16     1.77    1/1        start [1]
[2]    100.00    0.16     1.77    1      main [2]
                 1.77        0    1/1        a <cycle 1> [5]
----------------------------------------
                 1.77        0    1/1        main [2]
[3]     91.71    1.77        0    1+5    <cycle 1 as a whole> [3]
                 1.02        0    3          b <cycle 1> [4]
                 0.75        0    2          a <cycle 1> [5]
                    0        0    6/6        c [6]
----------------------------------------
                                  3          a <cycle 1> [5]
[4]     52.85    1.02        0    0      b <cycle 1> [4]
                                  2          a <cycle 1> [5]
                    0        0    3/6        c [6]
----------------------------------------
                 1.77        0    1/1        main [2]
                                  2          b <cycle 1> [4]
[5]     38.86    0.75        0    1      a <cycle 1> [5]
                                  3          b <cycle 1> [4]
                    0        0    3/6        c [6]
----------------------------------------
                    0        0    3/6        b <cycle 1> [4]
                    0        0    3/6        a <cycle 1> [5]
[6]      0.00       0        0    6      c [6]
----------------------------------------
@end smallexample

The @code{self} field of the cycle's primary line is the total time
spent in all the functions of the cycle.  It equals the sum of the
@code{self} fields for the individual functions in the cycle, found
in the entry in the subroutine lines for these functions.

The @code{children} fields of the cycle's primary line and subroutine lines
count only subroutines outside the cycle.  Even though @code{a} calls
@code{b}, the time spent in those calls to @code{b} is not counted in
@code{a}'s @code{children} time.  Thus, we do not encounter the problem of
what to do when the time in those calls to @code{b} includes indirect
recursive calls back to @code{a}.

The @code{children} field of a caller-line in the cycle's entry estimates
the amount of time spent @emph{in the whole cycle}, and its other
subroutines, on the times when that caller called a function in the cycle.

The @code{calls} field in the primary line for the cycle has two numbers:
first, the number of times functions in the cycle were called by functions
outside the cycle; second, the number of times they were called by
functions in the cycle (including times when a function in the cycle calls
itself).  This is a generalization of the usual split into non-recursive and
recursive calls.

The @code{calls} field of a subroutine-line for a cycle member in the
cycle's entry says how many time that function was called from functions in
the cycle.  The total of all these is the second number in the primary line's
@code{calls} field.

In the individual entry for a function in a cycle, the other functions in
the same cycle can appear as subroutines and as callers.  These lines show
how many times each function in the cycle called or was called from each other
function in the cycle.  The @code{self} and @code{children} fields in these
lines are blank because of the difficulty of defining meanings for them
when recursion is going on.

@node Line-by-line,Annotated Source,Call Graph,Output
@section Line-by-line Profiling

@code{gprof}'s @samp{-l} option causes the program to perform
@dfn{line-by-line} profiling.  In this mode, histogram
samples are assigned not to functions, but to individual
lines of source code.  The program usually must be compiled
with a @samp{-g} option, in addition to @samp{-pg}, in order
to generate debugging symbols for tracking source code lines.

The flat profile is the most useful output table
in line-by-line mode.
The call graph isn't as useful as normal, since
the current version of @code{gprof} does not propagate
call graph arcs from source code lines to the enclosing function.
The call graph does, however, show each line of code
that called each function, along with a count.

Here is a section of @code{gprof}'s output, without line-by-line profiling.
Note that @code{ct_init} accounted for four histogram hits, and
13327 calls to @code{init_block}.

@smallexample
Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  us/call  us/call  name    
 30.77      0.13     0.04     6335     6.31     6.31  ct_init


		     Call graph (explanation follows)


granularity: each sample hit covers 4 byte(s) for 7.69% of 0.13 seconds

index % time    self  children    called     name

                0.00    0.00       1/13496       name_too_long
                0.00    0.00      40/13496       deflate
                0.00    0.00     128/13496       deflate_fast
                0.00    0.00   13327/13496       ct_init
[7]      0.0    0.00    0.00   13496         init_block

@end smallexample

Now let's look at some of @code{gprof}'s output from the same program run,
this time with line-by-line profiling enabled.  Note that @code{ct_init}'s
four histogram hits are broken down into four lines of source code - one hit
occurred on each of lines 349, 351, 382 and 385.  In the call graph,
note how
@code{ct_init}'s 13327 calls to @code{init_block} are broken down
into one call from line 396, 3071 calls from line 384, 3730 calls
from line 385, and 6525 calls from 387.

@smallexample
Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self                    
 time   seconds   seconds    calls  name    
  7.69      0.10     0.01           ct_init (trees.c:349)
  7.69      0.11     0.01           ct_init (trees.c:351)
  7.69      0.12     0.01           ct_init (trees.c:382)
  7.69      0.13     0.01           ct_init (trees.c:385)


		     Call graph (explanation follows)


granularity: each sample hit covers 4 byte(s) for 7.69% of 0.13 seconds

  % time    self  children    called     name

            0.00    0.00       1/13496       name_too_long (gzip.c:1440)
            0.00    0.00       1/13496       deflate (deflate.c:763)
            0.00    0.00       1/13496       ct_init (trees.c:396)
            0.00    0.00       2/13496       deflate (deflate.c:727)
            0.00    0.00       4/13496       deflate (deflate.c:686)
            0.00    0.00       5/13496       deflate (deflate.c:675)
            0.00    0.00      12/13496       deflate (deflate.c:679)
            0.00    0.00      16/13496       deflate (deflate.c:730)
            0.00    0.00     128/13496       deflate_fast (deflate.c:654)
            0.00    0.00    3071/13496       ct_init (trees.c:384)