If you look at Common Lisp the Language, the book which provided the initial definition of the language, you find the goals listed. One of the goals for the lan

If you look at Common Lisp the Language, the book which provided the initial definition of the language, you find the goals listed. One of the goals for the language Common Lisp was 'efficiency' - that's slightly different from 'high performance', but somewhat in that direction. Thus it was expected that Common Lisp was to be implemented on supercomputers. For example Allegro CL had a port to one of the early Cray systems. To support the goal of 'efficiency' Common Lisp provides: type declarations, inline declarations, compiler policy settings, compiler macros, a 'file compiler', compile-time macros, compiler macros, a disassembler, a timing macro, low-level type-specific functions, low level control structures like gotos, ... One thing it lacked was 'TCO', tail call optimization, but that was something many implementations of CL provided. A few compilers were written to support this goal of efficiency. For example CMUCL (which provided type inference and 'block compilation') and Lucid Common Lisp. Lucid CL had two compilers: one for interactive use and one for application delivery. The latter did much more optimizations and also supported 'block compilation' (the compiler optimizes the code not only inside a file scope, but also on a collection of files). Other commercial compilers like Allegro CL and LispWorks were improving efficiency over time, based on customer requests. Customers had written applications and they wanted to improve their speed: numeric computations, object and record slot access, garbage collection, ... were examples. Thus not also the compiler, but also the runtime had to be efficient.