It is generally only worth profiling code which has been compiled. If you profile interpreted code, the interpreter itself is profiled, and this skews the results for the actual Lisp program.
Macros cannot be profiled because they are expanded during the compilation process. Similarly, the compiler may transform some functions such that they are present in the source code but not in the compiled code.
For example, the compiler transforms this source expression:
(member 'x '(x y z) :test #'eq)
into this compiled expression:
(memq 'x '(x y z))
Therefore function
memq
will appear instead of
member
in the profile results.
Similarly, you cannot profile inlined functions.
Recursive functions need special attention. A recursive function may well be found on the stack in more than one place during one interrupt. The profiler counts each occurrence of the function, and so the total number of times a function is found on the stack may be greater than the number of times the stack is examined.
You must take care when profiling structure accessors. These compile down into a call to a closure, of which there is one for all structure setters and one for all structure getters. Therefore it is not possible to profile individual structure setters or getters by name.
Even if you configure the profiler to profile all the known functions of an application, it is possible that less than 100% of the time is spent monitoring the top function. This is because an internal system function could be on the top of the stack at the time of the interrupt.