5.13.2 Efficiency Notes and Type Checking

     

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.