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