gjc@mitech.COM (08/22/90)
Well, at least in a VMS or UNIX environment we use things called Performance and Coverage analysis tools. For a C program they sample the machine program counter by realtime, cputime, etc, and can tell us what lines of code have been executed and how much time is being spent in each line of codt!e.z The old MIT-CADR lispmachine environment had similar tools, but unfortunately: (1) the coorespondence back to "line of code " or even S-expression/subexpression was lost during the compilation process. (The VMS compilers and PCA keep good track of this info anyway, and so do the various Unix tools) (2) the *commercial* lispmachine products just as the Symbolics 36xxx "lost" these old CADR tools, instead of improving upon them, and it wasn't until many years later that such tools showed up again in the commercial lispmachine implementations. The LMI-LAMBDA did better in this regard, but only because the microcode was upward compatible from the old MIT-CADR. (3) as far as commercial lisp implementations on conventional machines, you can forget about even trying to DEBUG compiled code, much less profiling it at the level of detail that C/FORTRAN/PASCAL implementations allow. However, I can think of one way to optimize your lisp program. Use a reasonable LISP->C translator, and then compile and profile the resulting C program. Then somehow work the information gained back through a reverse translation process. A LISP->C which would at least emit #line C-preprocessor constructs would be a very servicable for this purpose. -gjc
jeff@aiai.edinburgh.ac.UK (Jeff Dalton) (08/23/90)
> The old MIT-CADR lispmachine environment had similar tools, but > unfortunately: > (1) the coorespondence back to "line of code > " or even S-expression/subexpression was lost during the compilation > process. (The VMS compilers and PCA keep good track of this info > anyway, and so do the various Unix tools) > (3) as far as commercial lisp implementations on conventional machines, > you can forget about even trying to DEBUG compiled code, much less > profiling it at the level of detail that C/FORTRAN/PASCAL implementations > allow. Indeed, I find it somewhat ironic that Lisp, a language famous for its associtaion with powerful programming environments, should almost always come with tools that are much worse than those available for C. I'd pick dbxtool over most of the Lisp debuggers any day. -- Jeff