From 43bc8de9f926b47538648d38e1327d42f84c779a Mon Sep 17 00:00:00 2001 From: Juho Snellman Date: Sat, 15 Oct 2005 17:36:20 +0000 Subject: [PATCH] 0.9.5.67: The CODE->FOO-MAPPER functions generated by DEFINE-UNIBYTE-MAPPER are very large, and inlined a lot. This caused both large slowdowns in SBCL builds and a lot of core file bloat (700k on x86-64). Remove the inlining. --- src/code/octets.lisp | 9 ++++++++- version.lisp-expr | 2 +- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/src/code/octets.lisp b/src/code/octets.lisp index 751a039..b7dbfd0 100644 --- a/src/code/octets.lisp +++ b/src/code/octets.lisp @@ -174,7 +174,7 @@ one-past-the-end" (defmacro define-unibyte-mapper (byte-char-name code-byte-name &rest exceptions) `(progn - (declaim (inline ,byte-char-name ,code-byte-name)) + (declaim (inline ,byte-char-name)) (defun ,byte-char-name (byte) (declare (optimize speed (safety 0)) (type (unsigned-byte 8) byte)) @@ -186,9 +186,16 @@ one-past-the-end" exception byte)))) byte)) + ;; This used to be inlined, but it caused huge slowdowns in SBCL builds, + ;; bloated the core by about 700k on x86-64. Removing the inlining + ;; didn't seem to have any performance effect. -- JES, 2005-10-15 (defun ,code-byte-name (code) (declare (optimize speed (safety 0)) (type char-code code)) + ;; FIXME: I'm not convinced doing this with CASE is a good idea as + ;; long as it's just macroexpanded into a stupid COND. Consider + ;; for example the output of (DISASSEMBLE 'SB-IMPL::CODE->CP1250-MAPPER) + ;; -- JES, 2005-10-15 (case code ,@(mapcar (lambda (exception) (destructuring-bind (byte code) exception diff --git a/version.lisp-expr b/version.lisp-expr index 44d0379..c901feb 100644 --- a/version.lisp-expr +++ b/version.lisp-expr @@ -17,4 +17,4 @@ ;;; checkins which aren't released. (And occasionally for internal ;;; versions, especially for internal versions off the main CVS ;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".) -"0.9.5.66" +"0.9.5.67" -- 1.7.10.4