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
169 total time spent in them; there is no record of how many times they
199 somewhat slower than normal because of the time spent collecting and
207 the time used in initialization and in cleanup, but not much else.
222 directory_ at the time it exits. This means that if your program calls
472 outside the file/function/block where they were defined.) Time
514 in a large function a program is spending its time, it also
515 significantly increases the running time of `gprof', and magnifies
525 `--time=SYMSPEC'
530 `--no-time=SYMSPEC'
538 no time spent in them. This is useful in conjunction with the
600 The `-E FUNCTION' option works like the `-e' option, but time
603 percentages-of-time for the call graph. More than one `-E' option
614 The `-F FUNCTION' option works like the `-f' option, but only time
616 will be used to determine total-time and percentages-of-time for
695 * Flat Profile:: The flat profile shows how much time was spent
698 others, and how much time each function used
710 The "flat profile" shows the total amount of time your program spent
712 with no apparent time spent in them, and no apparent calls to them, are
723 time seconds seconds calls ms/call ms/call name
740 The functions are sorted first by decreasing run-time spent in them,
743 appear in every flat profile; their time gives a measure of the amount
747 much time each sample counted as. This "sampling period" estimates the
748 margin of error in each of the time figures. A time figure that is not
751 program's total execution time was 0.06 seconds, as indicated by the
766 Clearly some time was spent executing these functions, but the paucity
767 of histogram samples prevents any determination of how much time each
772 `% time'
773 This is the percentage of the total execution time your program
778 executing this functions, plus the time spent in all the functions
814 The "call graph" shows how much time was spent in each function and its
816 they themselves may not have used much time, called other functions
817 that did use unusual amounts of time.
824 index % time self children called name
860 The entries are sorted by time spent in the function and its
888 index % time self children called name
904 `% time'
905 This is the percentage of the total time that was spent in this
906 function, including time spent in subroutines called from this
909 The time spent in this function is counted again for the callers of
914 This is the total amount of time spent in this function. This
919 This is the total amount of time spent in the subroutine calls
960 index % time self children called name
969 An estimate of the amount of time spent in `report' itself when it
973 An estimate of the amount of time spent in subroutines of `report'
977 amount of time spent within calls to `report' from `main'.
1015 index % time self children called name
1024 An estimate of the amount of time spent directly within `report'
1028 An estimate of the amount of time spent in subroutines of `report'
1032 total time spent in calls to `report' from `main'.
1038 `children' time gets credited to `main'. *Note Estimating
1067 belongs to a cycle, each time the function name appears in the call
1070 The reason cycles matter is that they make the time values in the
1071 call graph paradoxical. The "time spent in children" of `a' should
1072 include the time spent in its subroutine `b' and in `b''s
1074 time should be included in the children of `a', when `a' is indirectly
1079 total time spent directly in the functions of the cycle. The
1089 index % time self children called name
1112 index % time self children called name
1143 The `self' field of the cycle's primary line is the total time spent
1150 `b', the time spent in those calls to `b' is not counted in `a''s
1151 `children' time. Thus, we do not encounter the problem of what to do
1152 when the time
1156 the amount of time spent _in the whole cycle_, and its other
1168 cycle's entry says how many time that function was called from
1212 time seconds seconds calls us/call us/call name
1221 index % time self children called name
1230 this time with line-by-line profiling enabled. Note that `ct_init''s
1241 time seconds seconds calls name
1253 % time self children called name
1346 through the loop. One of those times (the last time) it exited, while
1366 The run-time figures that `gprof' gives you are based on a sampling
1368 runs only a small amount of time, so that on the average the sampling
1379 run-time figure is accurate if it is considerably bigger than the
1384 period is 0.01 seconds and `foo''s run-time is 1 second, N is 100
1386 error in `foo''s run-time is 0.1 seconds (10*0.01 seconds), or ten
1388 seconds and `bar''s run-time is 100 seconds, N is 10000 samples,
1389 sqrt(N) is 100 samples, so the expected error in `bar''s run-time is 1
1394 This does not mean that a small run-time figure is devoid of
1395 information. If the program's _total_ run-time is large, a small
1396 run-time for one function does tell you that that function used an
1397 insignificant fraction of the whole program's time. Usually this means
1428 `children' time values and all the time figures in caller and
1435 The assumption made is that the average time spent in each call to
1438 then `foo' contributes 2 seconds to `a''s `children' time, by
1445 all the time spent in `foo' is in the calls from callers other than `a'.
1447 charge 2 seconds of time in `foo' to the children of `a'.
1463 is spending its time is to re-factor large functions into sequences
1584 times per second of run time, but the exact frequency may vary from
1604 delivered to user space every time a sample is taken, it uses
1616 Rather, the `mcount' routine, when it is invoked for the first time
1621 counts, initially zero. In the executable code, every time a new
1624 array. At compile time, a paired array was constructed that recorded
1638 run time. Therefore, the time measurements in `gprof' output say
1639 nothing about time that your program was not running. For example, a
1642 `gprof' will say it uses little time. On the other hand, sampling by
1643 run time has the advantage that the amount of load due to other users
1689 representing real-time would specify the long name as "seconds" and the
1765 symbol table entry gets created every time the line number changes. In
1806 divided by the number of bins) must be the same. The time unit must be
1852 computes the fraction of child time to propagate to each parent and a
1861 discarded, and a new array of pointers is assembled, this time sorted
1862 by propagated time.
2079 location until at least one year after the last time you
2264 the GNU Free Documentation License from time to time. Such new