0.9.5.67:
authorJuho Snellman <jsnell@iki.fi>
Sat, 15 Oct 2005 17:36:20 +0000 (17:36 +0000)
committerJuho Snellman <jsnell@iki.fi>
Sat, 15 Oct 2005 17:36:20 +0000 (17:36 +0000)
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
version.lisp-expr

index 751a039..b7dbfd0 100644 (file)
@@ -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
index 44d0379..c901feb 100644 (file)
@@ -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"