SBCL Internals The pages on this CLiki-driven site can be edited by anybody at any time. No warranty of any kind can therefore be made; any implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed

The cl-bench benchmark suite attempts to measure various aspects of a lisp system's performance: automatically generated graphs for SBCL, maintained by Andreas Fuchs?, are available at his site (test version).

WHN: The system's performance has suffered from code rot. I've made extensive changes and, while I use regression tests to keep me from making the system not work, but I haven't done analogous performance checks. There are probably a number of relatively easy code fixes which would help. One area where this is particularly likely is in VOPs and transforms which aren't missing, just not being invoked for some subtle reason or another. Everyone who's worked on a port seems to have had the same problems that I've had, that you change something innocent and oops! now an important transform or VOPs stops working. In the original massive restructuring to make SBCL bootstrap itself, I ran into dozens of those which were severe enough to keep the system from booting, and I fixed them. Very likely there are many left which don't keep the system from booting but which do impact performance.

WHN: There are also some extra reasons why the compiler itself is slower. (1) I got rid of the code to pool and reuse nodes, so it GCs substantially more than the old CMU CL compiler did. (2) When I rewrote parts of the type system to make intersection types work, I didn't bother to memoize, or continue to memoize, some results which really ought to be memoized, so things are being recomputed from scratch too often.

WHN: I suspect that the cost to benefit ratio of some work on this would be high. I personally would like to work on increasing the speed of the compiler pretty soon, since it's fallow ground and I expect big easy improvements are possible. I'd also like to make some form of block compilation properly supported again, preferably at the same time as the compiler's large-compilation-unit asymptotic time is reduced to something reasonable.

WHN: Two other performance issues that I've noticed -- dunno whether they're shared with CMU CL or not -- where I suspect that the payoff would be pretty high are (1) too many runtime calls to %TYPEP, when it should be possible to inline the type test, and (2) type information not getting propagated all the way into some complicated expressions.

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively