[net.unix] prof question

jpayne%bbn-vax@sri-unix.UUCP (01/30/84)

From:  Jonathan Payne <jpayne@bbn-vax>

I have some questions about the output from prof:
First of all, if proc1() calls proc2(), does the time spent in proc2() get
added to proc1()'s time?

What does "Beware of quantization errors," in the manual entry mean?

Thanks,
	jonathan

gwyn%brl-vld@sri-unix.UUCP (01/31/84)

From:      Doug Gwyn (VLD/VMB) <gwyn@brl-vld>

Profiling samples one's process every so often (clock tick typically)
and records where the PC (program counter) is each sample.  This data
is stored as a histogram with "bin width" usually equal to several
bytes.  The "quantization errors" can take three forms:
	- All PC locations within a bin are counted together;
	- Since the sampling is periodic it may not be representative
	  of the real PC distribution due to beating with code
	  periodicities (especially if code and sampling are driven by
	  the same clock);
	- Because the code is sampled rather than exhaustively traced,
	  some sections can be missed, and in general Poisson sampling
	  statistics apply (i.e. sampling error for a bin is roughly
	  the square root of the bin count).

Each subroutine on "prof" output summary includes only the time spent
in its PC range, so a call to another routine will result in time
spent in the called routine being tallied under its name rather than
under the caller's name.

nather@utastro.UUCP (Ed Nather) (02/01/84)

<>
From:      Doug Gwyn (VLD/VMB) <gwyn@brl-vld>

	Profiling samples one's process every so often (clock tick typically)
	and records where the PC (program counter) is each sample.
             *       *              *          *            *
		- Since the sampling is periodic it may not be representative
		  of the real PC distribution due to beating with code
		  periodicities (especially if code and sampling are driven by
		  the same clock);
		- Because the code is sampled rather than exhaustively traced,
		  some sections can be missed, and in general Poisson sampling
		  statistics apply (i.e. sampling error for a bin is roughly
		  the square root of the bin count).

I must disagree about Poisson statistics -- in fact, the first quoted point
above explains beautifully why they *don't* apply.   The basis of Poisson
statistical description is that the population from which the sample is
drawn (in this case, the times spent by the program in its various parts)
is randomly distributed in the sampled parameter.  If beating occurs this
assumption is seriously violated.  True, the "central limit theorum" says
if you sample non-random stuff for long enough it begins to look random,
but my experiences with "prof" suggest the effects are more erratic than
random.  With random distributions statistical predictions are possible.
With erratic ones, you're on your own -- and good luck!
-- 

                                       Ed Nather
                                       ihnp4!{ut-sally,kpno}!utastro!nather

thomas@utah-gr.UUCP (Spencer W. Thomas) (02/03/84)

4.2Bsd comes with gprof, which will count time spent in sub-function
calls into the time for a given function.  In fact, it has a very fancy
time distribution function.  Furthermore, it tells you the call graph
for your program (i.e., who called who, and how many times).  Much more
useful, in many circumstances, than prof.  It was described in a paper
in SIGPLAN (I forget exactly, but it was a conference proceedings, in
1982, I think).

=Spencer