Re: profilers

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

          From comp.compilers

Related articles
profilers (Waverly Edwards) (1997-12-05)
Re: profilers (William A. Barath) (1997-12-07)
Re: profilers (1997-12-10)
Re: profilers (Barry Martin) (1997-12-10)
Re: profilers (Tony DeWitt) (1997-12-10)
Re: profilers debray@CS.Arizona.EDU (1997-12-12)
Re: profilers (Chris F Clark) (1997-12-12)
Re: profilers (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 <> 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
>[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

Post a followup to this message

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