Lines Matching refs:time
52 execution time. We assume that you know how to write, compile, and
75 execution time. We assume that you know how to write, compile, and
119 [ --[no-]time=@var{name}] [ --all-lines ] [ --brief ]
148 @code{Gprof} calculates the amount of time spent in each routine.
150 Cycles are discovered, and calls into a cycle are made to share the time
158 We assume that the time for each execution of a function
159 can be expressed by the total time for the function divided
161 Thus the time propagated along the call graph arcs to the function's
165 Parents that are not themselves profiled will have the time of
168 not have their time propagated further.
206 Profiling allows you to learn where your program spent its time and which
243 The @dfn{flat profile} shows how much time your program spent in each function,
250 of how much time was spent in the subroutines of each function. This can
252 lot of time. @xref{Call Graph, ,The Call Graph}.
300 graph data you will still be able to see the time samples:
307 time seconds seconds calls Ts/call Ts/call name
344 you get for the functions in those modules is the total time spent in them;
372 somewhat slower than normal because of the time spent collecting and
379 to your program is to quit, the profile data will show the time used in
394 directory} at the time it exits. This means that if your program calls
707 a program is spending its time, it also significantly increases
708 the running time of @code{gprof}, and magnifies statistical
723 @itemx --time=@var{symspec}
728 @itemx --no-time=@var{symspec}
743 that had no time spent in them. This is useful in conjunction with the
806 time spent in the function (and children who were not called from
807 anywhere else), will not be used to compute the percentages-of-time for
820 only time spent in the function and its children (and their
821 children@dots{}) will be used to determine total-time and
822 percentages-of-time for the call graph. More than one @samp{-F} option
906 * Flat Profile:: The flat profile shows how much time was spent
909 others, and how much time each function used
921 The @dfn{flat profile} shows the total amount of time your program
923 functions with no apparent time spent in them, and no apparent calls
937 time seconds seconds calls ms/call ms/call name
957 The functions are sorted first by decreasing run-time spent in them,
960 apparatus and appear in every flat profile; their time gives a measure of
964 how much time each sample counted as.
965 This @dfn{sampling period} estimates the margin of error in each of the time
966 figures. A time figure that is not much larger than this is not
969 The program's total execution time was 0.06
990 Clearly some time was spent executing these functions,
992 determination of how much time each took.
997 @item % time
998 This is the percentage of the total execution time your program spent
1003 executing this functions, plus the time spent in all the functions
1037 The @dfn{call graph} shows how much time was spent in each function
1039 while they themselves may not have used much time, called other
1040 functions that did use unusual amounts of time.
1050 index % time self children called name
1088 The entries are sorted by time spent in the function and its subroutines.
1114 index % time self children called name
1132 @item % time
1133 This is the percentage of the total time that was spent in this
1134 function, including time spent in subroutines called from this
1137 The time spent in this function is counted again for the callers of
1141 This is the total amount of time spent in this function. This
1146 This is the total amount of time spent in the subroutine calls made by
1189 index % time self children called name
1200 An estimate of the amount of time spent in @code{report} itself when it was
1204 An estimate of the amount of time spent in subroutines of @code{report}
1208 of the amount of time spent within calls to @code{report} from @code{main}.
1248 index % time self children called name
1259 An estimate of the amount of time spent directly within @code{report}
1263 An estimate of the amount of time spent in subroutines of @code{report}
1267 of the total time spent in calls to @code{report} from @code{main}.
1273 and @code{children} time gets credited to @code{main}.
1303 belongs to a cycle, each time the function name appears in the call graph
1306 The reason cycles matter is that they make the time values in the call
1307 graph paradoxical. The ``time spent in children'' of @code{a} should
1308 include the time spent in its subroutine @code{b} and in @code{b}'s
1310 @code{a}'s time should be included in the children of @code{a}, when
1315 total time spent directly in the functions of the cycle. The
1326 index % time self children called name
1352 index % time self children called name
1384 The @code{self} field of the cycle's primary line is the total time
1391 @code{b}, the time spent in those calls to @code{b} is not counted in
1392 @code{a}'s @code{children} time. Thus, we do not encounter the problem of
1393 what to do when the time in those calls to @code{b} includes indirect
1397 the amount of time spent @emph{in the whole cycle}, and its other
1408 cycle's entry says how many time that function was called from functions in
1453 time seconds seconds calls us/call us/call name
1462 index % time self children called name
1473 this time with line-by-line profiling enabled. Note that @code{ct_init}'s
1486 time seconds seconds calls name
1498 % time self children called name
1599 each iteration through the loop. One of those times (the last time)
1613 The run-time figures that @code{gprof} gives you are based on a sampling
1615 only a small amount of time, so that on the average the sampling process
1630 run-time figure is accurate if it is considerably bigger than the sampling
1636 if the sampling period is 0.01 seconds and @code{foo}'s run-time is 1 second,
1638 the expected error in @code{foo}'s run-time is 0.1 seconds (10*0.01 seconds),
1640 Again, if the sampling period is 0.01 seconds and @code{bar}'s run-time is
1642 the expected error in @code{bar}'s run-time is 1 second,
1648 This does not mean that a small run-time figure is devoid of information.
1649 If the program's @emph{total} run-time is large, a small run-time for one
1651 the whole program's time. Usually this means it is not worth optimizing.
1689 @code{children} time values and all the time figures in caller and
1696 The assumption made is that the average time spent in each call to any
1700 @code{children} time, by assumption.
1706 time spent in @code{foo} is in the calls from callers other than @code{a}.
1708 incorrectly charge 2 seconds of time in @code{foo} to the children of
1725 is spending its time is to re-factor large functions into sequences
1860 run time, but the exact frequency may vary from system to system.
1883 user space every time a sample is taken, it uses considerably
1899 the first time (typically when @code{main} is called),
1905 In the executable code, every time a new basic-block begins
1908 At compile time, a paired array was constructed that recorded
1921 program counter are taken at fixed intervals of the program's run time.
1923 time measurements in @code{gprof} output say nothing about time that your
1926 slowly due to thrashing, but @code{gprof} will say it uses little time. On
1927 the other hand, sampling by run time has the advantage that the amount of
1969 histogram representing real-time would specify the long name as
2051 gets created every time the line number changes.
2102 bins) must be the same. The time unit must be the same for all
2157 computes the fraction of child time to propagate to each parent
2168 new array of pointers is assembled, this time sorted by propagated time.
2239 note: time estimates now only go out to one decimal place (0.0), where