Lines Matching full:time
23 Profiling a Program: Where Does It Spend Its Time?
28 time. We assume that you know how to write, compile, and execute
57 Profiling allows you to learn where your program spent its time and
88 The "flat profile" shows how much time your program spent in each
95 an estimate of how much time was spent in the subroutines of each
97 function calls that use a lot of time. *Note Call Graph::.
140 graph data you will still be able to see the time samples:
146 time seconds seconds calls Ts/call Ts/call name
151 % the percentage of the total running time of the
168 total time spent in them; there is no record of how many times they
209 somewhat slower than normal because of the time spent collecting and the
217 the time used in initialization and in cleanup, but not much else.
232 directory_ at the time it exits. This means that if your program calls
482 outside the file/function/block where they were defined.) Time
521 spending its time, it also significantly increases the running
522 time of `gprof', and magnifies statistical inaccuracies. *Note
531 `--time[=SYMSPEC]'
536 `--no-time[=SYMSPEC]'
544 no time spent in them. This is useful in conjunction with the
605 The `-E FUNCTION' option works like the `-e' option, but time
608 percentages-of-time for the call graph. More than one `-E' option
619 The `-F FUNCTION' option works like the `-f' option, but only time
621 will be used to determine total-time and percentages-of-time for
700 * Flat Profile:: The flat profile shows how much time was spent
703 others, and how much time each function used
715 The "flat profile" shows the total amount of time your program spent
717 with no apparent time spent in them, and no apparent calls to them, are
728 time seconds seconds calls ms/call ms/call name
745 The functions are sorted by first by decreasing run-time spent in them,
748 appear in every flat profile; their time gives a measure of the amount
752 much time each sample counted as. This "sampling period" estimates the
753 margin of error in each of the time figures. A time figure that is not
756 program's total execution time was 0.06 seconds, as indicated by the
771 Clearly some time was spent executing these functions, but the paucity
772 of histogram samples prevents any determination of how much time each
777 `% time'
778 This is the percentage of the total execution time your program
783 executing this functions, plus the time spent in all the functions
819 The "call graph" shows how much time was spent in each function and its
821 they themselves may not have used much time, called other functions
822 that did use unusual amounts of time.
829 index % time self children called name
865 The entries are sorted by time spent in the function and its
893 index % time self children called name
909 `% time'
910 This is the percentage of the total time that was spent in this
911 function, including time spent in subroutines called from this
914 The time spent in this function is counted again for the callers of
919 This is the total amount of time spent in this function. This
924 This is the total amount of time spent in the subroutine calls
965 index % time self children called name
974 An estimate of the amount of time spent in `report' itself when it
978 An estimate of the amount of time spent in subroutines of `report'
982 amount of time spent within calls to `report' from `main'.
1020 index % time self children called name
1029 An estimate of the amount of time spent directly within `report'
1033 An estimate of the amount of time spent in subroutines of `report'
1037 total time spent in calls to `report' from `main'.
1043 `children' time gets credited to `main'. *Note Assumptions::.
1071 belongs to a cycle, each time the function name appears in the call
1074 The reason cycles matter is that they make the time values in the
1075 call graph paradoxical. The "time spent in children" of `a' should
1076 include the time spent in its subroutine `b' and in `b''s
1078 time should be included in the children of `a', when `a' is indirectly
1083 total time spent directly in the functions of the cycle. The
1093 index % time self children called name
1116 index % time self children called name
1147 The `self' field of the cycle's primary line is the total time spent
1154 `b', the time spent in those calls to `b' is not counted in `a''s
1155 `children' time
1156 when the time in those calls to `b' includes indirect recursive calls
1160 the amount of time spent _in the whole cycle_, and its other
1172 cycle's entry says how many time that function was called from
1209 time seconds seconds calls us/call us/call name
1218 index % time self children called name
1227 this time with line-by-line profiling enabled. Note that `ct_init''s
1238 time seconds seconds calls name
1250 % time self children called name
1339 through the loop. One of those times (the last time) it exited, while
1359 The run-time figures that `gprof' gives you are based on a sampling
1361 runs only a small amount of time, so that on the average the sampling
1372 run-time figure is accurate if it is considerably bigger than the
1377 period is 0.01 seconds and `foo''s run-time is 1 second, N is 100
1379 error in `foo''s run-time is 0.1 seconds (10*0.01 seconds), or ten
1381 seconds and `bar''s run-time is 100 seconds, N is 10000 samples,
1382 sqrt(N) is 100 samples, so the expected error in `bar''s run-time is 1
1387 This does not mean that a small run-time figure is devoid of
1388 information. If the program's _total_ run-time is large, a small
1389 run-time for one function does tell you that that function used an
1390 insignificant fraction of the whole program's time. Usually this means
1421 `children' time values and all the time figures in caller and
1428 The assumption made is that the average time spent in each call to
1431 then `foo' contributes 2 seconds to `a''s `children' time, by
1438 all the time spent in `foo' is in the calls from callers other than `a'.
1440 charge 2 seconds of time in `foo' to the children of `a'.
1456 is spending its time is to re-factor large functions into sequences
1469 often, but not necessarily those that consumed the most time.
1583 times per second of run time, but the exact frequency may vary from
1603 delivered to user space every time a sample is taken, it uses
1615 Rather, the `mcount' routine, when it is invoked for the first time
1620 counts, initially zero. In the executable code, every time a new
1623 array. At compile time, a paired array was constructed that recorded
1637 run time. Therefore, the time measurements in `gprof' output say
1638 nothing about time that your program was not running. For example, a
1641 `gprof' will say it uses little time. On the other hand, sampling by
1642 run time has the advantage that the amount of load due to other users
1688 representing real-time would specify the long name as "seconds" and the
1764 symbol table entry gets created every time the line number changes. In
1850 computes the fraction of child time to propagate to each parent and a
1859 discarded, and a new array of pointers is assembled, this time sorted
1860 by propagated time.
2070 until at least one year after the last time you distribute an Opaque
2240 the GNU Free Documentation License from time to time. Such new
