Re: profilers

debray@CS.Arizona.EDU (Saumya K. Debray)
12 Dec 1997 14:45:18 -0500

          From comp.compilers

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)
| List of all articles for this month |

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
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.