Re: profilers

"William A. Barath" <wi534@victoria.tc.ca> writes:


>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. Easy, little overhead, little bloat, and accurate even if
>the timer is only good for milliseconds (due to the averaging effect
>of repeated updates.) I've never done it, but it seems quite
>reasonable.
>
>[That's what Unix C compilers do with the -p flag. -John]


Are you sure? I thought Unix C compilers inserted profiling code that
recorded execution *counts* for each function, but that for doing the
actual timing they used PC-sampling techiques based on the use of
`setitimer(ITIMER_PROF, ...)' to schedule regular `SIGPROF' signals.


The Mercury distribution includes (Mercury) source code for a profiler
that can do both flat (prof-style) and call-graph (gprof-style)
profiles of Mercury programs, using this technique. It's available
via <http://www.cs.mu.oz.au/mercury>.


The current version only does time profiling, but we've recently been
doing some work on adding support for profiling memory allocation. Of
course profiling the allocations is the easy bit; in an environment
with garbage-collection, more detailed memory profiling information is
very desirable. There's been some useful work on this done in the
functional programming language community in recent years (I can dig
up some references if needed).


--
Fergus Henderson <fjh@cs.mu.oz.au>
WWW: <http://www.cs.mu.oz.au/~fjh>
PGP: finger fjh@128.250.37.3
[You're right, Unix profiling counts procedure calls but does statistical
timing. You'd need to have a high-res timer readable in application
programs and can either lock out interrupts or do something to account
for the time they take. -John]




--

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