1\" @(#)intro.me 1.8 03/14/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.pp 26Once a large program is executable, 27it is often desirable to increase its speed, 28especially if small portions of the program 29are found to dominate its execution time. 30The purpose of the \fBgprof\fP profiling tool is to 31help the user evaluate alternative implementations 32of abstractions. 33We developed this tool in response to our efforts 34to improve a code generator we were writing [Graham82]. 35.pp 36The \fBgprof\fP design takes advantage of the fact that the programs 37to be measured are large, structured and hierarchical. 38We provide a profile in which the execution time 39for a set of routines that implement an 40abstraction is collected and charged 41to that abstraction. 42The profile can be used to compare and assess the costs of 43various implementations. 44.pp 45The profiler can be linked into a program without 46special planning by the programmer. 47The overhead for using \fBgprof\fP is low; 48both in terms of added execution time and in the 49volume of profiling information recorded. 50