---- Running time & code efficiency ----

[Mark Moraes]

siping at cathedral.cerc.wvu.wvnet.edu (Siping Liu) writes:
>What is your favorate tool for timing analysis? I used "prof" but
>it did not give me the timing imformation for all functions in
>my program -- just a few functions were listed. I also used the
>system provided function called "times", it is pretty good.

gprof is very good -- not only does it show you which routines are
gobbling CPU, but where they're called from so you can identify why
they're gobbling CPU.  (As in, "who is calling malloc() a million times
and why?")  It also produces a flat prof(1) style profile.  [For those
with systems without gprof, gcc supports it, and the GNU binutils come
with gprof]

Paul Haahr posted a lovely tool called lcomp to comp.sources.unix back
in October 1989 (Volume 20, Issue 82).  It runs on Vaxen and Sun3s
(should work on most of 68k family with pcc compilers) that does
instruction counting (based on Peter Weinberger's paper on "Cheap
dynamic instruction counting" in Bell Labs Tech J, OCt 84 -- the gold
book) so you can see how often each line of source was executed.  Suns
also have something called tcov that does something similar -- I
remember trying it and preferring lcomp.

gprof gets you down to the function level, lcomp helps peer inside the
function. One can always emulate lcomp by sticking in counters by hand
in the appropriate places.

Working out the order of a program's run time is a little difficult
for large programs.  One can try to approximate times for typical
programs by finding the most executed code, (gprof is a great help)
and working out rough relationships for the input and the time taken.
It's a good way to figure out what the code is doing and why it's
taking so long doing it.

Jon Bentley's "Writing efficient programs" (Prentice-Hall) is
recommended reading.  I liked Dennie Van Tassel's "Program Design,
Style, Efficiency and Testing" (?).  And you can always pick up the C
News paper from Usenix '87 (Winter?) or by anon. ftp from
cs.toronto.edu (doc/programming/cnews.{tbl.ms,doc,ps}) -- has some
interesting lessons on speeding up system programs.

	Mark.