gprof/PSD.doc/intro.me

\"	@(#)intro.me	1.4 03/12/82
.ls 2
.sh 1 "Programs to be Profiled"
.pp
Software research environments
normally include many large programs
both for  production use and for experimental investigation.
These programs are typically very modular,
in accordance with generally accepted principles
of good program design.
Often they consist of numerous small routines
that implement various abstractions.
Sometimes such large programs are written
by one programmer
who has understood the requirements for
these abstractions, and has programmed them
appropriately.
More frequently the program has
had multiple authors and has
evolved over time, changing the demands placed
on the implementation of the abstractions without
changing the implementation itself.
Finally, the program may be assembled from a library
of abstraction implementations
unexamined by the programmer.
.pp
Once a large program is executable,
it is often desirable to increase its speed,
especially if small portions of the program
are found to dominate its execution time.
The purpose of the \fBgprof\fP profiling tool is to
help the user evaluate alternative implementations
of abstractions.
In fact, we developed this tool in response to our efforts
to improve a code generator we were writing [Graham82].
.pp
The \fBgprof\fP design takes advantage of the fact that the programs
to be measured are large, structured and hierarchical.
We provide a profile in which the execution time
for a set of routines that implement an
abstraction is collected and charged
to that abstraction.
The profile can be used to compare and assess the costs of
various implementations.
.pp
The profiler can be compiled into a program without
any prior planning on the part of the programmer.
Depending on the ratio of subroutine calls to computation,
it adds only five to thirty percent execution overhead to the profiled program.
Finally, it produces no output until after the program finishes,
and allows the program to be measured in its actual environment.