From a2e934ad4e9545f1c6bbd8a9e9d3dd4d1c4698d9 Mon Sep 17 00:00:00 2001 From: Nikodemus Siivola Date: Mon, 4 Aug 2008 12:00:58 +0000 Subject: [PATCH] 1.0.19.19: manual updates * Four patches from Xan Lopez on sbcl-devel, one slightly adjusted. * Document slot access efficiency issues. --- NEWS | 2 ++ doc/manual/compiler.texinfo | 18 +++++++----- doc/manual/efficiency.texinfo | 63 +++++++++++++++++++++++++++++++++++++++-- doc/manual/intro.texinfo | 4 +-- version.lisp-expr | 2 +- 5 files changed, 76 insertions(+), 13 deletions(-) diff --git a/NEWS b/NEWS index 7db39be..ea29431 100644 --- a/NEWS +++ b/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. diff --git a/doc/manual/compiler.texinfo b/doc/manual/compiler.texinfo index 35284f3..9a3533d 100644 --- a/doc/manual/compiler.texinfo +++ b/doc/manual/compiler.texinfo @@ -516,16 +516,17 @@ 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))} @@ -533,6 +534,9 @@ 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 diff --git a/doc/manual/efficiency.texinfo b/doc/manual/efficiency.texinfo index de905ae..8ef22d2 100644 --- a/doc/manual/efficiency.texinfo +++ b/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 diff --git a/doc/manual/intro.texinfo b/doc/manual/intro.texinfo index 2795d9a..26b1307 100644 --- a/doc/manual/intro.texinfo +++ b/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 diff --git a/version.lisp-expr b/version.lisp-expr index d8136f2..8e51dbc 100644 --- a/version.lisp-expr +++ b/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" -- 1.7.10.4