1.0.19.19: manual updates

 * Four patches from Xan Lopez on sbcl-devel, one slightly adjusted.

 * Document slot access efficiency issues.

NEWS

@@ -4,6 +4,8 @@ changes in sbcl-1.0.20 relative to 1.0.19:
     SB-C::STACK-ALLOCATE-DYNAMIC-EXTENT, SB-C::STACK-ALLOCATE-VECTOR,
     and SB-C::STACK-ALLOCATE-VALUE-CELLS no longer exist. See documentation
     and SB-EXT:*STACK-ALLOCATE-DYNAMIC-EXTENT* for details.
+  * documentation: some slot access efficiency guidelines have been
+    added to the user manual.
   * optimization: ASSOC-IF, ASSOC-IF-NOT, MEMBER-IF, MEMBER-IF-NOT,
     RASSOC, RASSOC-IF, and RASSOC-IF-NOT are now equally efficient
     as ASSOC and MEMEBER.

doc/manual/compiler.texinfo

@@ -516,23 +516,27 @@ selectable via @code{optimize} declarations.
 
 @item Full Type Checks
 All declarations are considered assertions to be checked at runtime,
-and all type checks are precise.
+and all type checks are precise. The default compilation policy
+provides full type checks.
 
-Used when @code{(and (< 0 safety) (or (>= safety 2) (>= safety speed)))}. The
-default compilation policy provides full type checks.
+Used when @code{(or (>= safety 2) (>= safety speed 1))}.
 
 @item Weak Type Checks
-Any or all type declarations may be believed without runtime
-assertions, and assertions that are done may be imprecise. It should
-be noted that it is relatively easy to corrupt the heap when weak type
-checks are used, and type-errors are introduced into the program.
+Declared types may be simplified into faster to check supertypes: for example,
+@code{(and unsigned-byte fixnum)} is simplified into @code{fixnum}.
+
+@strong{Note}: it is relatively easy to corrupt the heap when weak
+type checks are used if the program contains type-errors.
 
 Used when @code{(and (< safety 2) (< safety speed))}
 
 @item No Type Checks
 All declarations are believed without assertions. Also disables
 argument count and array bounds checking.
 
+@strong{Note}: any type errors in code where type checks are not
+performed are liable to corrupt the heap.
+
 Used when @code{(= safety 0)}.
 
 @end table

doc/manual/efficiency.texinfo

@@ -4,11 +4,68 @@
 @cindex Efficiency
 
 @menu
-* Dynamic-extent allocation::
-* Modular arithmetic::
-* Miscellaneous Efficiency Issues::
+* Slot access::                 
+* Dynamic-extent allocation::   
+* Modular arithmetic::          
+* Miscellaneous Efficiency Issues::  
 @end menu
 
+@node  Slot access
+@comment  node-name,  next,  previous,  up
+@section Slot access
+@cindex Slot access
+
+@subsection Structure object slot access
+
+Structure slot accessors are efficient only if the compiler is able to
+open code them: compiling a call to a structure slot accessor before
+the structure is defined, declaring one @code{notinline}, or passing
+it as a functional argument to another function causes severe
+perfomance degradation.
+
+@subsection Standard object slot access
+
+The most efficient way to access a slot of a @code{standard-object} is
+by using @code{slot-value} with a constant slot name argument inside a
+@code{defmethod} body, where the variable holding the instance is a
+specializer parameter of the method and is never assigned to. The cost
+is roughly 1.6 times that of an open coded structure slot accessor.
+
+Second most efficient way is to use a CLOS slot accessor, or
+@code{slot-value} with a constant slot name argument, but in
+circumstances other than specified above. This may be up to 3 times as
+slow as the method described above.
+
+Example:
+
+@lisp
+(defclass foo () ((bar)))
+
+;; Fast: specializer and never assigned to
+(defmethod quux ((foo foo) new)
+  (let ((old (slot-value foo 'bar)))
+    (setf (slot-value foo 'bar) new)
+    old))
+
+;; Slow: not a specializer
+(defmethod quux ((foo foo) new)
+  (let* ((temp foo)
+         (old (slot-value temp 'bar)))
+    (setf (slot-value temp 'bar) new)
+    old))
+
+;; Slow: assignment to FOO
+(defmethod quux ((foo foo) new)
+  (let ((old (slot-value foo 'bar)))
+    (setf (slot-value foo 'bar) new)
+    (setf foo new)
+    old))
+@end lisp
+
+Note that when profiling code such as this, the first few calls to the
+generic function are not representative, as the dispatch mechanism is
+lazily set up during those calls.
+
 @node  Dynamic-extent allocation
 @comment  node-name,  next,  previous,  up
 @section Dynamic-extent allocation

doc/manual/intro.texinfo

@@ -494,7 +494,7 @@ freely available at @uref{http://www.lisp.org/mop/}.
 @comment  node-name,  next,  previous,  up
 @section History and Implementation of SBCL
 
-You can work productively with SBCL without knowing anything
+You can work productively with SBCL without knowing or
 understanding anything about where it came from, how it is
 implemented, or how it extends the ANSI Common Lisp standard. However,
 a little knowledge can be helpful in order to understand error
@@ -544,7 +544,7 @@ can't be used interactively, and in fact the change is largely invisible
 to the casual user, since SBCL still can and does execute code
 interactively by compiling it on the fly. (It is visible if you know how
 to look, like using @code{compiled-function-p}; and it is visible in the
-way that that SBCL doesn't have many bugs which behave differently in
+way that SBCL doesn't have many bugs which behave differently in
 interpreted code than in compiled code.) What it means is that in SBCL,
 the @code{eval} function only truly ``interprets'' a few easy kinds of
 forms, such as symbols which are @code{boundp}. More complicated forms

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".)
-"1.0.19.18"
+"1.0.19.19"