moraes@cs.toronto.edu (Mark Moraes) (09/07/90)
Archive-name: lcomp/06-Sep-90 Original-posting-by: moraes@cs.toronto.edu (Mark Moraes) Original-subject: Re: ---- Running time & code efficiency ---- Archive-site: wuarchive.wustl.edu [128.252.135.4] Archive-directory: /usenet/comp.archives/volume20 Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti) siping@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.