1\" @(#)intro.me 1.9 03/15/82 2.sh 1 "Programs to be Profiled" 3.pp 4Software research environments 5normally include many large programs 6both for production use and for experimental investigation. 7These programs are typically modular, 8in accordance with generally accepted principles 9of good program design. 10Often they consist of numerous small routines 11that implement various abstractions. 12Sometimes such large programs are written 13by one programmer 14who has understood the requirements for 15these abstractions, and has programmed them 16appropriately. 17More frequently the program has 18had multiple authors and has 19evolved over time, changing the demands placed 20on the implementation of the abstractions without 21changing the implementation itself. 22Finally, the program may be assembled from a library 23of abstraction implementations 24unexamined by the programmer. 25.(z 26.sp 3i 27.)z 28.pp 29Once a large program is executable, 30it is often desirable to increase its speed, 31especially if small portions of the program 32are found to dominate its execution time. 33The purpose of the \fBgprof\fP profiling tool is to 34help the user evaluate alternative implementations 35of abstractions. 36We developed this tool in response to our efforts 37to improve a code generator we were writing [Graham82]. 38.pp 39The \fBgprof\fP design takes advantage of the fact that the programs 40to be measured are large, structured and hierarchical. 41We provide a profile in which the execution time 42for a set of routines that implement an 43abstraction is collected and charged 44to that abstraction. 45The profile can be used to compare and assess the costs of 46various implementations. 47.pp 48The profiler can be linked into a program without 49special planning by the programmer. 50The overhead for using \fBgprof\fP is low; 51both in terms of added execution time and in the 52volume of profiling information recorded. 53