Compilation Features

• Inline functions. You can define an inline function with defsubst. Use defsubst just like defun, and it defines a function which you can call in all the usual ways. Whenever the function thus defined is used in compiled code, the compiler will open code it. You can get somewhat the same effects with a macro, but a macro has the limitation that you can use it only explicitly; a macro cannot be called with apply, mapcar and so on. Also, it takes some work to convert an ordinary function into a macro. To convert it into an inline function, simply replace defun with defsubst. Making a function inline makes explicit calls run faster. But it also has disadvantages. For one thing, it reduces flexibility; if you change the definition of the function, calls already inlined still use the old definition until you recompile them. Another disadvantage is that making a large function inline can increase the size of compiled code both in files and in memory. Since the advantages of inline functions are greatest for small functions, you generally should not make large functions inline. Inline functions can be used and open coded later on in the same file, following the definition, just like macros.
• The command byte-compile-file now offers to save any buffer visiting the file you are compiling.
• The new command compile-defun reads, compiles and executes the defun containing point. If you use this on a defun that is actually a function definition, the effect is to install a compiled version of that function.
• Whenever you load a Lisp file or library, you now receive a warning if the directory contains both a `.el' file and a `.elc' file, and the `.el' file is newer. This typically indicates that someone has updated the Lisp code but forgotten to recompile it, so the changes do not take effect. The warning is a reminder to recompile.
• The special form eval-when-compile marks the forms it contains to be evaluated at compile time only. At top-level, this is analogous to the Common Lisp idiom (eval-when (compile) ...). Elsewhere, it is similar to the Common Lisp `#.' reader macro (but not when interpreting). If you're thinking of using this feature, we recommend you consider whether provide and require might do the job as well.
• The special form eval-and-compile is similar to eval-when-compile, but the whole form is evaluated both at compile time and at run time. If you're thinking of using this feature, we recommend you consider whether provide and require might do the job as well.
• Emacs Lisp has a new data type for byte-code functions. This makes them faster to call, and also saves space. Internally, a byte-code function object is much like a vector; however, the evaluator handles this data type specially when it appears as a function to be called. The printed representation for a byte-code function object is like that for a vector, except that it starts with `#' before the opening `['. A byte-code function object must have at least four elements; there is no maximum number, but only the first six elements are actually used. They are:

  arglist

  The list of argument symbols.

  byte-code

  The string containing the byte-code instructions.

  constants

  The vector of constants referenced by the byte code.

  stacksize

  The maximum stack size this function needs.

  docstring

  The documentation string (if any); otherwise, nil.

  interactive

  The interactive spec (if any). This can be a string or a Lisp expression. It is nil for a function that isn't interactive.

  The predicate byte-code-function-p tests whether a given object is a byte-code function. You can create a byte-code function object in a Lisp program with the function make-byte-code. Its arguments are the elements to put in the byte-code function object. You should not try to come up with the elements for a byte-code function yourself, because if they are inconsistent, Emacs may crash when you call the function. Always leave it to the byte compiler to create these objects; it, we hope, always makes the elements consistent.