Apple's CHUD tools have been distributed with the last several XCode releases. One way to determine whether or not the tools are installed is to run:

$ /usr/bin/shark -v

in a terminal or Emacs shell buffer. If that returns output like

shark 4.7.3 (365)

then the CHUD package is installed. Output like

shark: Command not found.

strongly suggests that it isn't ...

Shark can only properly identify functions that're defined in a shared library that's loaded by the target application. (Any other functions will be identified by a hex address described as being in an "Unknown Library"; the hex address is generally somewhat near the actual function, but it's determined heuristically and isn't always accurate.)

For those reasons, it's desirable to load the code that you wish to profile in one lisp session, save a native (Mach-O library) image, and invoke Shark in a new session which uses that native image. (It may also be useful to load the CHUD-METERING module, which defines CHUD:METER and friends.

[src/ccl-dev] gb@antinomial> ccl64
Welcome to Clozure Common Lisp Version 1.7-dev-r14624M-trunk  (DarwinX8664)!
? (defun fact(n) (if (zerop n) 1 (* n (fact (1- n)))))
FACT
? (require "CHUD-METERING")
"CHUD-METERING"
("CHUD-METERING")
? (save-application "ccl:dx86cl64.dylib" :native t)
[src/ccl-dev] gb@antinomial> ccl64 -I dx86cl64.dylib
Welcome to Clozure Common Lisp Version 1.7-dev-r14624M-trunk  (DarwinX8664)!
? (chud:meter (dotimes (i 1000) (fact 1000)))
;;; Waiting for shark to process samples ...done.
NIL

and, a few seconds after the result is returned, a file whose name is of the form "session_nnn.mshark" will open in Shark.app.

The fist time that CHUD:METER is used in a lisp session, it'll do a few things to prepare subsequent profiling sessions. Those things include:

This startup activity typically takes a few seconds; after it's been completed, subsequent use of CHUD:METER doesn't involve that overhead. (See the discussion of :RESET below.)

After any startup activity is complete, CHUD:METER arranges to send a "start profiling" signal to the running shark program, executes the form, sends a "stop profiling" signal to the shark program, and reads its diagnostic output, looking for the name of the ".mshark" file it produces. If it's able to find this filename, it arranges for "Shark.app" to open it.

By default, a shark profiling session will:

This is known as "the default configuration"; it's possible to use items on the "Config" menu in the Shark application to create alternate configurations which provide different kinds of profiling parameters and to save these configurations in files for subsequent reuse. (The set of things that CHUD knows how to monitor is large and interesting.)

You use alternate profiling configurations (created and "exported" via Shark.app) with CHUD:METER, but the interface is a little awkward.

CHUD:*SHARK-CONFIG-FILE* [Variable]

When non-null, this should be the pathname of an alternate profiling configuration file created by the "Config Editor" in Shark.app.

CHUD:METER form &key (reset nil) (debug-output nil) [Macro]

Executes FORM (an arbitrary lisp form) and returns whatever result(s) it returns, with CHUD profiling enabled during the form's execution. Tries to determine the name of the session file (*.mshark) to which the shark program wrote profiling data and opens this file in the Shark application.

Arguments:

Both Dan Knapp and Hamilton Link have posted similar CHUD interfaces to openmcl-devel in the past; Hamilton's also reported bugs in the spatch mechanism to CHUD developers (and gotten those bugs fixed.)