Compilation Tips

Here are some tips for making compiled code run fast:

• Always favour iteration over recursion; function calls are relatively slow. The compiler doesn't know about tail recursion or whatever so you'll have to do this explicitly. For example, the most elegant way of searching a list is to use recursion,

  (defun scan-list (list elt)
    "Search the LIST for an element ELT. Return it if one is found."
    (if (eq (car list) elt)
        elt
      (scan-list (cdr list) elt)))
  

  but this is fairly slow. Instead, iterate through each element,

  (defun scan-list (list elt)
    (while (consp list)
      (when (eq (car list) elt)
        (return elt))
      (setq list (cdr list))))
  

• In some cases the functions member, memq, assoc, etc... can be used to search lists. Since these are primitives written in C they will run much faster than an equivalent Lisp function. So the above scan-list example can be rewritten as,

  (defun scan-list (list elt)
    (car (memq elt list)))
  

  Also note that the mapcar and mapc functions are useful (and efficient) when using lists.
• Whenever possible use the when and unless conditional structures; they are more efficient than cond or if.
• Careful use of named constants (see section Constant Variables) can increase the speed of some programs. For example, in the Lisp compiler itself all the opcode values (small integers) are defined as constants. I must stress that in some cases constants are not suitable; they may drastically increase the size of the compiled program (when the constants are `big' objects, i.e. long lists) or even introduce subtle bugs (since two references to the same constant may not be eq whereas two references to the same variable are always eq).
• Many primitives have corresponding byte-code instructions; these primitives will be quicker to call than those that don't (and incur a normal function call). Currently, the functions which have byte-code instructions (apart from all the special forms) are: cons, car, cdr, rplaca, rplacd, nth, nthcdr, aset, aref, length, eval, +, *, /, %, lognot, not, logior, logand, equal, eq, =, /=, >, <, >=, <=, 1+, 1-, -, set, fset, lsh, zerop, null, atom, consp, listp, numberp, stringp, vectorp, throw, fboundp, boundp, symbolp, get, put, signal, return, reverse, nreverse, assoc, assq, rassoc, rassq, last, mapcar, mapc, member, memq, delete, delq, delete-if, delete-if-not, copy-sequence, sequencep, functionp, special-formp, subrp, eql, set-current-buffer, current-buffer, bufferp, markp, windowp.
• When a file is being compiled each top-level form it contains is inspected to see if it should be compiled into a byte-code form. Different types of form are processed in different ways:
  • Function and macro definitions have their body forms compiled into a single byte-code form. The doc-string and interactive declaration are not compiled.
  • Calls to the require function are evaluated then the unevaluated form is written as-is to the output file. The reason it is evaluated is so that any macros defined in the required module are loaded before they are called by the program being compiled.
  • If the form is a list form (see section List Forms) and the symbol which is the car of the list is one of: if, cond, when, unless, let, let*, catch, unwind-protect, error-protect, with-buffer, with-window, progn, prog1, prog2, while, and, or. then the form is compiled. Otherwise it is just written to the output file in its uncompiled state.
  If your program contains a lot of top-level forms which you know will not be compiled automatically, consider putting them in a progn block to make the compiler coalesce them into one byte-code form.

Go to the first, previous, next, last section, table of contents.