Commit | Line | Data |
---|---|---|
9f7329e7 | 1 | \" @(#)profiling.me 1.6 %G% |
fa7270bc PK |
2 | .sh 1 "Types of Profiling" |
3 | .pp | |
bded3f9b | 4 | There are several different uses for program profiles, |
fa7270bc PK |
5 | and each may require different information from the profiles, |
6 | or different presentation of the information. | |
7 | We distinguish two broad categories of profiles: | |
8 | those that present counts of statement or routine invocations, | |
9 | and those that display timing information about statements | |
10 | or routines. | |
11 | Counts are typically presented in tabular form, | |
12 | often in parallel with a listing of the source code. | |
dc7f8b19 | 13 | Timing information could be similarly presented; |
602c58f5 PK |
14 | but more than one measure of time might be associated with each |
15 | statement or routine. | |
dc7f8b19 PK |
16 | For example, |
17 | in the framework used by \fBgprof\fP | |
18 | each profiled segment would display two times: | |
fa7270bc PK |
19 | one for the time used by the segment itself, and another for the |
20 | time inherited from code segments it invokes. | |
21 | .pp | |
bded3f9b | 22 | Execution counts are used in many different contexts. |
fa7270bc PK |
23 | The exact number of times a routine or statement is activated |
24 | can be used to determine if an algorithm is performing as | |
25 | expected. | |
bded3f9b | 26 | Cursory inspection of such counters may show algorithms whose |
fa7270bc | 27 | complexity is unsuited to the task at hand. |
597923e1 | 28 | Careful interpretation of counters can often suggest |
fa7270bc PK |
29 | improvements to acceptable algorithms. |
30 | Precise examination can uncover subtle errors in an | |
31 | algorithm. | |
bded3f9b | 32 | At this level, profiling counters are similar to |
fa7270bc PK |
33 | debugging statements whose purpose is to show the number of times |
34 | a piece of code is executed. | |
35 | Another view of such counters is as boolean values. | |
36 | One may be interested that a portion of code has executed at | |
dc7f8b19 | 37 | all, for exhaustive testing, or to check that one implementation |
fa7270bc PK |
38 | of an abstraction completely replaces a previous one. |
39 | .pp | |
40 | Execution counts are not necessarily proportional to the amount | |
41 | of time required to execute the routine or statement. | |
42 | Further, the execution time of a routine will not be the same for | |
43 | all calls on the routine. | |
dc7f8b19 | 44 | The criteria for establishing execution time |
fa7270bc PK |
45 | must be decided. |
46 | If a routine implements an abstraction by invoking other abstractions, | |
47 | the time spent in the routine will not accurately reflect the | |
48 | time required by the abstraction it implements. | |
bded3f9b | 49 | Similarly, if an abstraction is implemented by several |
597923e1 | 50 | routines the time required by the abstraction will be distributed |
fa7270bc PK |
51 | across those routines. |
52 | .pp | |
bded3f9b | 53 | Given the execution time of individual routines, |
fa7270bc | 54 | \fBgprof\fP accounts to each routine the time spent |
bded3f9b | 55 | for it by the routines it invokes. |
dc7f8b19 | 56 | This accounting is done by assembling a \fIcall graph\fP with nodes that |
fa7270bc PK |
57 | are the routines of the program and directed arcs that represent |
58 | calls from call sites to routines. | |
59 | We distinguish among three different call graphs for a program. | |
60 | The \fIcomplete call graph\fP incorporates all routines and all | |
61 | potential arcs, | |
62 | including arcs that represent calls to functional parameters | |
602c58f5 | 63 | or functional variables. |
fa7270bc PK |
64 | This graph contains the other two graphs as subgraphs. |
65 | The \fIstatic call graph\fP includes all routines and all possible arcs | |
66 | that are not calls to functional parameters or variables. | |
67 | The \fIdynamic call graph\fP includes only those routines and | |
68 | arcs traversed by the profiled execution of the program. | |
69 | This graph need not include all routines, nor need it include all | |
70 | potential arcs between the routines it covers. | |
71 | It may, however, include arcs to functional parameters or | |
72 | variables that the static call graph may omit. | |
73 | The static call graph can be determined from the (static) program text. | |
74 | The dynamic call graph is determined only by profiling an | |
75 | execution of the program. | |
76 | The complete call graph for a monolithic program could be determined | |
77 | by data flow analysis techniques. | |
78 | The complete call graph for programs that change | |
79 | during execution, by modifying themselves or dynamically loading | |
80 | or overlaying code, may never be determinable. | |
9f7329e7 PK |
81 | Both the static call graph and the dynamic call graph are used |
82 | by \fBgprof\fP, but it does not search for the complete call | |
83 | graph. |