doc/efficiency.sgml

   1 <chapter id="efficiency"><title>Efficiency</>
   2
   3 <para>FIXME: The material in the &CMUCL; manual about getting good
   4 performance from the compiler should be reviewed, reformatted in
   5 DocBook, lightly edited for &SBCL;, and substituted into this
   6 manual. In the meantime, the original &CMUCL; manual is still 95+%
   7 correct for the &SBCL; version of the &Python; compiler. See the
   8 sections
   9 <itemizedlist>
  10   <listitem><para>Advanced Compiler Use and Efficiency Hints</></>
  11   <listitem><para>Advanced Compiler Introduction</></>
  12   <listitem><para>More About Types in Python</></>
  13   <listitem><para>Type Inference</></>
  14   <listitem><para>Source Optimization</></>
  15   <listitem><para>Tail Recursion</></>
  16   <listitem><para>Local Call</></>
  17   <listitem><para>Block Compilation</></>
  18   <listitem><para>Inline Expansion</></>
  19   <listitem><para>Object Representation</></>
  20   <listitem><para>Numbers</></>
  21   <listitem><para>General Efficiency Hints</></>
  22   <listitem><para>Efficiency Notes</></>
  23 </itemizedlist>
  24 </para>
  25
  26 <para>Besides this information from the &CMUCL; manual, there are a
  27 few other points to keep in mind.
  28 <itemizedlist>
  29   <listitem><para>The &CMUCL; manual doesn't seem to state it explicitly,
  30     but &Python; has a mental block about type inference when
  31     assignment is involved. &Python; is very aggressive and clever
  32     about inferring the types of values bound with <function>let</>,
  33     <function>let*</>, inline function call, and so forth. However,
  34     it's much more passive and dumb about inferring the types of
  35     values assigned with <function>setq</>, <function>setf</>, and
  36     friends. It would be nice to fix this, but in the meantime don't
  37     expect that just because it's very smart about types in most
  38     respects it will be smart about types involved in assignments.
  39     (This doesn't affect its ability to benefit from explicit type
  40     declarations involving the assigned variables, only its ability to
  41     get by without explicit type declarations.)</para></listitem>
  42   <listitem><para>Since the time the &CMUCL; manual was written,
  43     &CMUCL; (and thus &SBCL;) has gotten a generational garbage
  44     collector. This means that there are some efficiency implications
  45     of various patterns of memory usage which aren't discussed in the
  46     &CMUCL; manual. (Some new material should be written about
  47     this.)</para></listitem>
  48   <listitem><para>&SBCL; has some important known efficiency problems.
  49     Perhaps the most important are
  50     <itemizedlist>
  51       <listitem><para>There is no support for the &ANSI;
  52         <parameter>dynamic-extent</> declaration, not even for
  53         closures or <parameter>&amp;rest</> lists.</para></listitem>
  54       <listitem><para>The garbage collector is not particularly
  55         efficient.</para></listitem>
  56       <listitem><para>Various aspects of the PCL implementation
  57         of CLOS are more inefficient than necessary.</para></listitem>
  58     </itemizedlist>
  59   </para></listitem>
  60 </itemizedlist>
  61 </para>
  62
  63 <para>Finally, note that &CommonLisp; defines many constructs which, in
  64 the infamous phrase, <quote>could be compiled efficiently by a
  65 sufficiently smart compiler</quote>. The phrase is infamous because
  66 making a compiler which actually is sufficiently smart to find all
  67 these optimizations systematically is well beyond the state of the art
  68 of current compiler technology. Instead, they're optimized on a
  69 case-by-case basis by hand-written code, or not optimized at all if
  70 the appropriate case hasn't been hand-coded. Some cases where no such
  71 hand-coding has been done as of &SBCL; version 0.6.3 include
  72 <itemizedlist>
  73   <listitem><para><literal>(reduce #'f x)</>
  74     where the type of <varname>x</> is known at compile
  75     time</para></listitem>
  76   <listitem><para>various bit vector operations, e.g.
  77     <literal>(position 0 some-bit-vector)</></para></listitem>
  78 </itemizedlist>
  79 If your system's performance is suffering because of some construct
  80 which could in principle be compiled efficiently, but which the &SBCL;
  81 compiler can't in practice compile efficiently, consider writing a
  82 patch to the compiler and submitting it for inclusion in the main
  83 sources. Such code is often reasonably straightforward to write;
  84 search the sources for the string <quote><function>deftransform</></>
  85 to find many examples (some straightforward, some less so).</para>
  86
  87 </chapter>