Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| profilers Waverly@DigitSW.com (Waverly Edwards) (1997-12-05) |
| Re: profilers wi534@victoria.tc.ca (William A. Barath) (1997-12-07) |
| Re: profilers fjh@mundook.cs.mu.OZ.AU (1997-12-10) |
| Re: profilers bwm@bwmartin.demon.co.uk (Barry Martin) (1997-12-10) |
| Re: profilers adewitt@cs.cmu.edu (Tony DeWitt) (1997-12-10) |
| Re: profilers debray@CS.Arizona.EDU (1997-12-12) |
| Re: profilers cfc@world.std.com (Chris F Clark) (1997-12-12) |
| Re: profilers wi534@victoria.tc.canada (William A. Barath) (1997-12-12) |
| From: | debray@CS.Arizona.EDU (Saumya K. Debray) |
| Newsgroups: | comp.compilers |
| Date: | 12 Dec 1997 14:45:18 -0500 |
| Organization: | University of Arizona CS Department, Tucson AZ |
| References: | 97-12-017 97-12-046 |
| Keywords: | performance |
William A. Barath <wi534@victoria.tc.ca> wrote:
>The most efficient way I can imagine to do it is this: compile into
>each function a small code fragment at the entry and exit points which
>read a global variable containing the seed of a high-resolution timer
>and add the difference between the two reads to a table entry for that
>function.
[...]
>[That's what Unix C compilers do with the -p flag. -John]
However, this method won't work correctly for recursive functions.
Unix C compilers that use -p or -pg for profiling usually rely on
sampling techniques: the value of program counter is sampled periodically,
and use the distribution of samples to infer an execution profile. See:
S. Graham, P. Kessler, and M. McKusick,
"gprof: A Call Graph Execution Profiler",
Proc. SIGPLAN '82 Conf. on Compiler Construction
(SIGPLAN Notices vol 17 no 6, June 1982).
--
Saumya Debray
Dept. of Computer Science, University of Arizona, Tucson
debray@cs.arizona.edu
http://www.cs.arizona.edu/people/debray
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.