I noticed PROFILE-PACKAGE isn't implemented for SBCL. SBCL's native SB-PROFILE:PROFILE does support package-level profiling given a string argument. It has an interface somewhat like the one SLIME expects: it unprofiles and reprofiles already-profiled functions, although it does not support CALLERS-P or METHODS; I suppose that's why it isn't in the SBCL backend now. Even with this limitation, I find these patches useful:

Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.308 diff -r1.308 slime.el 4148,4149c4148,4151 < (y-or-n-p "Record the most common callers? ") < (y-or-n-p "Profile methods? "))) ---

                 (unless (string-match "sbcl" inferior-lisp-program)
                   (y-or-n-p "Record the most common callers? "))
                 (unless (string-match "sbcl" inferior-lisp-program)
                   (y-or-n-p "Profile methods? "))))

Index: swank-sbcl.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/swank-sbcl.lisp,v retrieving revision 1.85 diff -r1.85 swank-sbcl.lisp 534a535,541

;;; FIXME: This does not meaningfully support CALLERS-P or METHODS. (defimplementation profile-package (package callers-p methods) (when package (let ((package-name (string-upcase package))) (eval `(sb-profile:profile ,package-name)))) (format nil "Profiling all functions in package ~A." package))

Out of curiosity, are there any plans to use the included metering.lisp facility for all Lisp implementations, and not just CLISP? The current profiling hooks in SLIME expect a CMUCL-like interface, and supporting, e.g., the native profiler in Allegro CL would require either changing the front end (functions in slime.el need to ask different questions and provide different report options) or resorting to low-level hackery to make the other Lisps' profilers look like CMUCL's.