* Four patches from Xan Lopez on sbcl-devel, one slightly adjusted.
* Document slot access efficiency issues.
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.
@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))}
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
@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
@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
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
;;; 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"
projects / sbcl.git / commitdiff