Steel Bank Common Lisp

character set type unparsing slows down the compiler

Reported by Nikodemus Siivola on 2012-05-04
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Medium
Unassigned

Bug Description

Reported by maurycy on sbcl-bugs

Assuming that foo.lisp contains only the following code:

(defun foo (ch)
 (declare (character ch))
 (code-char (1+ (char-code ch))))

it takes a very long time and a lot of consing to compile it:

(time (compile-file #P"foo.lisp")) =>

Evaluation took:
 1.723 seconds of real time
 1.699889 seconds of total run time (1.189922 user, 0.509967 system)
 [ Run times consist of 0.414 seconds GC time, and 1.286 seconds non-GC time. ]
 98.67% CPU
 7 forms interpreted
 6 lambdas converted
 5,151,564,072 processor cycles
 206,028,768 bytes consed

For comparison, if the call to code-char is deleted, the compilation
takes only:

 97,244,919 processor cycles
 392,736 bytes consed

Nikodemus Siivola (nikodemus) wrote :

The issue is that the derived type of the function is represented as a massive MEMBER type.

The probable fix is to export CHARACTER-SET from SB-EXT, and allow character set types to unparse into (SB-EXT:CHARACTER-SET ...code-ranges...) instead of MEMBER types.

Nikodemus Siivola (nikodemus) wrote :

commit 33564311979de0cb8798884c377e491cfb416b95
Author: Nikodemus Siivola <email address hidden>
Date: Fri May 4 12:43:40 2012 +0300

    don't unconditionally unparse CHARACTER-SET types into MEMBER types

      Doing so means dumping a list containing most of unicode for each
      function that return something like

        (code-char (+ <const> <(integer 0)>))

      which has a derived type (CHARACTER-SET ((<const> . 1114111))).

      Instead, pick whichever is more compact, using number of characters
      vs number of character code ranges as the deciding factor.

      This means that users can see SB-KERNEL:CHARACTER-SET types in
      eg. output from DESCRIBE or as return values from
      SB-INTROSPECT:FUNCTION-TYPE -- which is suboptimal, but less bad
      than such types slowing us down as horribly as they do prior to this
      change.

      At some point, however, we should document and export SB-EXT:CHARSET
      or something -- but I don't want to think of the issues associated
      with a public interface right now.

Changed in sbcl:
status: Triaged → Fix Committed
Stas Boukarev (stassats) on 2012-05-21
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers