Next: Representation Efficiency Notes, Previous: Type Uncertainty, Up: Efficiency Notes [Contents][Index]
It is important that the eff-note
example above used
(safety 0)
. When type checking is enabled, you may get apparently
spurious efficiency notes. With (safety 1)
, the note has this extra
line on the end:
The result is a (INTEGER -1610612736 1610612733), not a FIXNUM.
This seems strange, since there is a the
declaration on the result of that
second addition.
In fact, the inefficiency is real, and is a consequence of Python’s treating declarations as assertions to be verified. The compiler can’t assume that the result type declaration is true—it must generate the result and then test whether it is of the appropriate type.
In practice, this means that when you are tuning a program to run
without type checks, you should work from the efficiency notes
generated by unsafe compilation. If you want code to run efficiently
with type checking, then you should pay attention to all the
efficiency notes that you get during safe compilation. Since user
supplied output type assertions (e.g., from the
) are
disregarded when selecting operation implementations for safe code,
you must somehow give the compiler information that allows it to prove
that the result truly must be of a good type. In our example, it
could be done by constraining the argument types more:
(defun eff-note (x y z) (declare (type (unsigned-byte 18) x y z)) (+ x y z))
Of course, this declaration is acceptable only if the arguments to eff-note
always are (unsigned-byte 18)
integers.
Next: Representation Efficiency Notes, Previous: Type Uncertainty, Up: Efficiency Notes [Contents][Index]