Hmm, that "hello" executable is 43M for me, for anyone who is interested.

The 40 or so unix utilities I have Lisp replacements for, have binaries on average 43% smaller than thier C equivalents. When you do a fair comparison and add the whole C tool chain and libraries, then they also compare well to the small programs with the whole Lisp runtime.

The article also provides us with this info:

"The :executable t keyword argument includes the SBCL runtime in the image to ensure that the image is a standalone executable. This is why the executable for even a simple hello-world program tends to be quite large (30 MB to 50 MB)!"

Hopefully somekind of total package, no libraries required.

    ls -alh /usr/bin/sbcl
    -rwxr-xr-x 1 root root 304K helmi 28  2018 /usr/bin/sbcl

    -rwxr-xr-x 1 root root 314K Feb  5  2020 /usr/bin/sbcl*

What is the size of your hello executable? I tried stripping it, but then it started SBCL's REPL for me. Perhaps I could strip something specific, but I did not have the time to mess around with it yet. But yeah, perhaps that executable contains SBCL along with other stuff.

The SBCL image and executable contains the full Lisp with compiler.

One thing one can do is to compress the image:

http://www.sbcl.org/manual/#Saving-a-Core-Image

Some other Common Lisp implementations have smaller executables and/or provide tools to reduce the size for delivery (for example by using a tree shaker).

Image compression prevents mmap of the image, however, which can hinder performance significantly in exchange for a modest storage savings.

Thank you!

I tried fibonacci test. It was also 43M. But fib(40) was 20 times faster than in Clisp. Something was compiled indeed. Who cares about the program size nowadays.

For those that want to do lisp on embedded, binary size can be very important.

I mentioned it because a lot of people do. Personally it does not affect me.