You can turn that off by setting or binding sb-ext:*evaluator-mode* to :interpret.
Also, on my machine, compiling the identity lambda form takes about 200 usec with (optimize (compilation-speed 3) (debug 0)). SBCL could use a faster JIT mode, perhaps at compilation-speed 3/speed 0. Perhaps there are some other internal special variables that could be tweaked to reduce compile time.
When calling EVAL it can be much faster to use the interpreter than to go through the compiler. This has bitten me in the past. A faster compiler would get around that.
One of the competing open Common Lisp implementations, CCL, has a much faster compiler (albeit one that produces worse code). This can be useful in development.
Compiling to bytecode is still compilation. An interpreter would operate directly on the S-expressions. Obviously, this makes some constructs (such as TAGBODY) very inefficient.
Comments
Not in typical builds of SBCL: all code is compiled before evaluation.
You can turn that off by setting or binding sb-ext:*evaluator-mode* to :interpret.
Also, on my machine, compiling the identity lambda form takes about 200 usec with (optimize (compilation-speed 3) (debug 0)). SBCL could use a faster JIT mode, perhaps at compilation-speed 3/speed 0. Perhaps there are some other internal special variables that could be tweaked to reduce compile time.
Are you sure this is actually makes a difference in your build?
Mine doesn't have the SB-INTERPRETER package, so I doubt binding the variable has an effect.
When calling EVAL it can be much faster to use the interpreter than to go through the compiler. This has bitten me in the past. A faster compiler would get around that.
One of the competing open Common Lisp implementations, CCL, has a much faster compiler (albeit one that produces worse code). This can be useful in development.
Eval would count as JIT compilation though[0]
[0] https://www.sbcl.org/manual/#compiler-only-implementation
It depends on the implementation. CLISP compiles when it is told to.
Last I checked, CLISP compiles to byte code. Did they add a JITter for the byte code?
Compiling to bytecode is still compilation. An interpreter would operate directly on the S-expressions. Obviously, this makes some constructs (such as TAGBODY) very inefficient.
There is a jit branch, but not in master.