Lines Matching full:time
22 Profiling a Program: Where Does It Spend Its Time?
27 time. We assume that you know how to write, compile, and execute
58 Profiling allows you to learn where your program spent its time and
89 The "flat profile" shows how much time your program spent in each
96 an estimate of how much time was spent in the subroutines of each
98 function calls that use a lot of time. *Note The Call Graph: Call
143 graph data you will still be able to see the time samples:
149 time seconds seconds calls Ts/call Ts/call name
180 total time spent in them; there is no record of how many times they
210 somewhat slower than normal because of the time spent collecting and
218 the time used in initialization and in cleanup, but not much else.
233 directory_ at the time it exits. This means that if your program calls
483 outside the file/function/block where they were defined.) Time
525 in a large function a program is spending its time, it also
526 significantly increases the running time of `gprof', and magnifies
536 `--time=SYMSPEC'
541 `--no-time=SYMSPEC'
556 no time spent in them. This is useful in conjunction with the
618 The `-E FUNCTION' option works like the `-e' option, but time
621 percentages-of-time for the call graph. More than one `-E' option
632 The `-F FUNCTION' option works like the `-f' option, but only time
634 will be used to determine total-time and percentages-of-time for
713 * Flat Profile:: The flat profile shows how much time was spent
716 others, and how much time each function used
728 The "flat profile" shows the total amount of time your program spent
730 with no apparent time spent in them, and no apparent calls to them, are
741 time seconds seconds calls ms/call ms/call name
758 The functions are sorted first by decreasing run-time spent in them,
761 appear in every flat profile; their time gives a measure of the amount
765 much time each sample counted as. This "sampling period" estimates the
766 margin of error in each of the time figures. A time figure that is not
769 program's total execution time was 0.06 seconds, as indicated by the
784 Clearly some time was spent executing these functions, but the paucity
785 of histogram samples prevents any determination of how much time each
790 `% time'
791 This is the percentage of the total execution time your program
796 executing this functions, plus the time spent in all the functions
832 The "call graph" shows how much time was spent in each function and its
834 they themselves may not have used much time, called other functions
835 that did use unusual amounts of time.
842 index % time self children called name
878 The entries are sorted by time spent in the function and its
906 index % time self children called name
922 `% time'
923 This is the percentage of the total time that was spent in this
924 function, including time spent in subroutines called from this
927 The time spent in this function is counted again for the callers of
932 This is the total amount of time spent in this function. This
937 This is the total amount of time spent in the subroutine calls
978 index % time self children called name
987 An estimate of the amount of time spent in `report' itself when it
991 An estimate of the amount of time spent in subroutines of `report'
995 amount of time spent within calls to `report' from `main'.
1033 index % time self children called name
1042 An estimate of the amount of time spent directly within `report'
1046 An estimate of the amount of time spent in subroutines of `report'
1050 total time spent in calls to `report' from `main'.
1056 `children' time gets credited to `main'. *Note Estimating
1085 belongs to a cycle, each time the function name appears in the call
1088 The reason cycles matter is that they make the time values in the
1089 call graph paradoxical. The "time spent in children" of `a' should
1090 include the time spent in its subroutine `b' and in `b''s
1092 time should be included in the children of `a', when `a' is indirectly
1097 total time spent directly in the functions of the cycle. The
1107 index % time self children called name
1130 index % time self children called name
1161 The `self' field of the cycle's primary line is the total time spent
1168 `b', the time spent in those calls to `b' is not counted in `a''s
1169 `children' time. Thus, we do not encounter the problem of what to do
1170 when the time in those calls to `b' includes indirect recursive calls
1174 the amount of time spent _in the whole cycle_, and its other
1186 cycle's entry says how many time that function was called from
1230 time seconds seconds calls us/call us/call name
1239 index % time self children called name
1248 this time with line-by-line profiling enabled. Note that `ct_init''s
1259 time seconds seconds calls name
1271 % time self children called name
1364 through the loop. One of those times (the last time) it exited, while
1384 The run-time figures that `gprof' gives you are based on a sampling
1386 runs only a small amount of time, so that on the average the sampling
1397 run-time figure is accurate if it is considerably bigger than the
1402 period is 0.01 seconds and `foo''s run-time is 1 second, N is 100
1404 error in `foo''s run-time is 0.1 seconds (10*0.01 seconds), or ten
1406 seconds and `bar''s run-time is 100 seconds, N is 10000 samples,
1407 sqrt(N) is 100 samples, so the expected error in `bar''s run-time is 1
1412 This does not mean that a small run-time figure is devoid of
1413 information. If the program's _total_ run-time is large, a small
1414 run-time for one function does tell you that that function used an
1415 insignificant fraction of the whole program's time. Usually this means
1446 `children' time values and all the time figures in caller and
1453 The assumption made is that the average time spent in each call to
1456 then `foo' contributes 2 seconds to `a''s `children' time, by
1463 all the time spent in `foo' is in the calls from callers other than `a'.
1465 charge 2 seconds of time in `foo' to the children of `a'.
1481 is spending its time is to re-factor large functions into sequences
1602 times per second of run time, but the exact frequency may vary from
1622 delivered to user space every time a sample is taken, it uses
1634 Rather, the `mcount' routine, when it is invoked for the first time
1639 counts, initially zero. In the executable code, every time a new
1642 array. At compile time, a paired array was constructed that recorded
1656 run time. Therefore, the time measurements in `gprof' output say
1657 nothing about time that your program was not running. For example, a
1660 `gprof' will say it uses little time. On the other hand, sampling by
1661 run time has the advantage that the amount of load due to other users
1707 representing real-time would specify the long name as "seconds" and the
1783 symbol table entry gets created every time the line number changes. In
1824 divided by the number of bins) must be the same. The time unit must be
1870 computes the fraction of child time to propagate to each parent and a
1879 discarded, and a new array of pointers is assembled, this time sorted
1880 by propagated time.
2126 location until at least one year after the last time you
2341 violation by some reasonable means, this is the first time you have
2355 the GNU Free Documentation License from time to time. Such new
2400 site under CC-BY-SA on the same site at any time before August 1,
