2009/9/17 David Neu <david@...>:
> I'm trying to put together some tools to support use of the
> deterministic profiler. I saw an approach at
> http://menzies.us/csx72/?154 in which functions in cl-user were
> explicitly excluded from profiling. I was wondering if it would be
> possible to optionally include them, and ended up with the code listed
> below. The approach seems to work well when cl-user is excluded, but
> runs into trouble, e.g. drops into the ldb or complains of corrupting
> the image when they are included.
CL-USER is unlikely to be the problem. I bet problem is in trying to
profile certain internals and/or standard CL functions -- eg.
MAKE-HASH-TABLE breaks if you redefine (which deterministic aka
_instrumenting_ profiling does) EQUAL.
In an ideal world PROFILE would have a good idea of which functions
are not safe to profile, and would refuse to do so. This state of
grace does not, unfortunately, exist yet.
As for FIND-FUNCTIONS-TO-PROFILE, DO-SYMBOLS goes through all symbols
in the package -- including those whose home-package is something
else. You might want to consider
(do-symbols (s package)
(when (eq package (symbol-package s))
to filter out those originating in other packages -- such as
COMMON-LISP, or other internal packages that do not take kindly to
Apropos, are you aware that you can just do (PROFILE
"NAME-OF-MY-PACKAGE") to profile functions in your package directly?
(I would suggest SB-SPROF as the better default approach to profiling,
and using PROFILE as the fallback tool. SB-SPROF is very good at
getting at the big picture, and copes with CLOS heavy programs much
better than PROFILE.)