Common Lisp was designed to be interactive and have a REPL. You can redefine functions, classes, etc. on the fly with strictly-defined semantics. (You don’t have to guess what happens if you, say, re-name a field of your class.) This is
insanely useful during development, where you absolutely want to avoid doing full recompiles every time you make a little change you want to test. Some people call this “interactive and incremental development”. (Of course, you always have the option to just re-compile everything from scratch if you so please.)
Common Lisp was also designed to be compiled. Most implementations these days compile to machine code. Compilation is incremental, but ahead-of-time. That means you can start running your program without having yet compiled all the features or libraries you want. You can—while you’re in the REPL or even while your program is running—compile and load extra libraries later. Compilation is cached across sessions, so you won’t ever have to recompile something that doesn’t change.
Despite Lisp being mega-interactive, incremental, and dynamic, just about every implementation of Lisp allows you to just write out a compiled binary. In the implementation called “Steel Bank Common Lisp” (SBCL), from the REPL, you just write:
(sb-ext:save-lisp-and-die "mycoolprog" :executable t :entry-point 'main)
which will produce a statically linked executable binary called “mycoolprog” using the function called “main” as the entry point.
Unless you’ve specifically programmed it in, there will be no JIT lag, no runtime compilation, etc. It will all just be compiled machine code running at the speed of your processor. (It’s possible and even easy to invoke the compiler at run-time, even in your static binary, which people rarely do, and when they do, they know exactly what they’re doing and why.)
All of this is a complete non-issue in Lisp, and hasn’t been for about 35 years (or more).