trickey@alice.UUCP (02/11/87)
What do people do to find out where the time is going in a
large common lisp program? I recently cut the run time of
a large compiled-lisp program by a factor of 5 by finding
out that my elegant general all-shortest-paths finding
routine (taking a node list and adjacency function, returning
functions for the shortest path and length between pairs)
was taking 90% of the time, and needed replacing by a faster
specialized one that left the answer in a global.
I found this by inserting calls to get-internal-cpu-time in
various places. But it seems like there should be something
like the time profiling we're used to with C, etc. It seems
possible to put in a SYSCALL of profil (I'm using Lucid
Common Lisp 1.2, on a Sun), and analyzing the results.
(Garbage collection should be turned off, assumptions made
about how the loader loads .lbins). Has anyone done this?
It's possible to redefine defun to accumulate counts, or even
times, but the timing resolution isn't fine enough for the
latter to work for all but the longest functions.
You might be interested to know that I've implemented the
same program (a graph layout program) in Common Lisp and
C++, about 8000 lines each. The C++ version is now 2 to 3
times faster (it was 10-20 times faster before I discovered
the shortest-paths thing, about the only place where there was
a significant difference between the two versions). This
is better than I expected for Common Lisp. I think it is because
so much time is spent doing shortest paths, and I spent time
making the CL version as fast as possible.
Howard Trickey, AT&T Bell Laboratories {allegra,research}!trickeymhb@wdl1.UUCP (02/14/87)
I'm fascinated by ther performance difference between the C++ version and CL. Based on the final code what is your feeling about readability? Time required to generate the code? etc. Mike Bender
steve@ztivax.UUCP (02/18/87)
/* Written 3:18 am Feb 11, 1987 by trickey@alice in ztivax:comp.lang.lisp */
/* ---------- "Common Lisp Performance Analysis" ---------- */
What do people do to find out where the time is going in a
large common lisp program? I recently cut the run time of
a large compiled-lisp program by a factor of 5 [...]
I found this by inserting calls to get-internal-cpu-time in
various places. But it seems like there should be something
like the time profiling we're used to with C, etc. [...]
(I'm using Lucid Common Lisp 1.2, on a Sun) [...]
Howard Trickey, AT&T Bell Laboratories {allegra,research}!trickey
/* End of text from ztivax:comp.lang.lisp */
If you want useful tools in your Lisp, then use Interlisp-D. Even though
Interlisp-D development is at a standstill as Xerox shifts to Common
Lisp, it will still be a LOOOOOOOOOOOOOONG time before Common Lisp will
have the tools a real lisp programmer needs. (For your performance
problem, use SPY - it gives you a graphic display of where your program
spends its time, and you can do lots of useful things with the graph.
And it's almost trivial to use.)
Someone recently advertized his ignorance of Interlisp on the net by
stating something to the effect that he didn't need a spaghetti stack
therefore he didn't need Interlisp. <sound of GONG> (I assume he means
Interlisp-D, the version on lisp machines.) I know I'm fighting a losing
battle, but I swear, Interlisp-D as an environment has it all over
any other lisp.
Steve Clark
Have fun trying to get mail to me:
EUNET: unido!ztivax!steve
Usenet: ...{ihnp4!princeton or topaz}!siemens!steve
CSNET: approximately steve@siemens.siemens-rtl.com
(maybe .csnet instead of .com; maybe leave out the first "siemens.")