character set type unparsing slows down the compiler

Bug #994487 reported by Nikodemus Siivola on 2012-05-04
This bug affects 1 person
Affects Status Importance Assigned to Milestone

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

      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