Hacker News Reader

Comment by mark_l_watson | Hacker News Reader

This certainly looks interesting, but it might help generate interest if the landing page addressed two questions: what is the application size overhead (how large is a hello world app) and what is the app startup overhead.

I used to make standalone apps from SBCL Common Lisp, and they were not too large (even though SBCL has no tree shaker unused code remover).

View on HN

This doesn't include ceramic, but:

I did a benchmark of executable image sizes and startup times for the popular open-source implementations[1] it depends on cl-launch since asdf:program-op was still experimental at the time.

A few points I discovered:

SBCL and CCL are neck-on-neck for startup time; very slightly longer than a hello-world in python, but much faster than any python script that has to do any significant importing.

SBCL has by far the largest image size overhead ~80MB for "hello world". It has an option to compress the image with zlib, but that is a big impact on image startup time. I did a proof of concept of an lz4hc image compressor, and it made for acceptable startup times while taking the overhead down to under 30MB. Someone else turned this into a real patch, and it is waiting to be merged.

CCL's image size is about 1/2 that of sbcl.

ECL has, by far, the smallest image size, even including the DLL (3.2MB for a lisp runtime is tiny!). However, it has a startup time that is two orders of magnitude higher than sbcl/ccl

clisp was ind the middle of things; executable image was about double that of ecl, it's startup performance is better.

1: https://github.com/jasom/image-bench

Thanks for the info on CCL's image size - that makes CCL worth switching to for bundling applications, but your SBCL patch sounds even better. That said, it has been a number of years since I sold a Lisp application - but still good to know!

I agree final app size would be a further selling point for me too. I am glad to see Lisp, CL, in the headlines other than clojure. I guess the ubiquity of JS has lead to the possibility Ceramic offers due to Electron. Slightly, OT, but I am reading 'The Handbook of Neuroevolution Through Erlang', and I am waiting to learn enough Erlang to jump over to using LFE (Lisp flavored Erlang) mid-book. @mark_l_watson, I started with your 'Common Lisp Modules:..' book, and now I am hooked on AI, NN and Lisp. Thanks!

Rob

Thanks! Richard Stallman asked me several years ago about releasing my old Lisp book under a FSF documentation license, but I can't find my old manuscript files. Maybe I will ask my wife to re-type it all.

What about crowdsourcing the job? I'm sure people would be willing to help.

I am glad to see Lisp, CL, in the headlines other than clojure.

We've had a string of really cool lisp projects this year, web frameworks, implementations, web servers, libraries, etc. Couple that with Edi Weitz's upcoming book, it's as exiting to be a lisper now as ever. Hack gloriously and eat your parenthesis for breakfast my lispy friends :)

wow that's an expensive book! even the ebook is $150

Which? Mark's book or the Erlang book I cited above?

Mark's book can be found used for $3.00 on Amazon.

Certainly not my book :-)

Edi's upcoming book on Amazon is listed as $56, due December 2015. I will probably buy a copy when it ships.

EDIT: I just pre ordered a copy on Amazon to lock in that price.

Which book are you referring to here?

Edi Weitz's "Common Lisp Recipes: A Problem-Solution Approach", listed on Amazon for December 2015.

Thanks for the $3 Amazon reference. I only have one copy of my (very) old book, and just ordered a used copy so I have a spare. I was surprised to see that Springer Verlag still sells it new - I thought that it was out of print a long time ago.

The Erlang book direct from publisher has to be one of the highest ebook prices I've ever seen.

The hello world app (bundle) is like 250 megabytes. Half of that is the Electron release, the rest is the Lisp image, whose size you can cut significantly using core compression (this isn't enabled, I'm looking into doing it through Buildapp without it crashing if it's not available).

Yikes. One would think that could be pared down by a significant amount: Node is only ~40mb installed, and the various webkit browsers aren't much bigger than that.

See my other comment about implementations' core image sizes. SBCL is the worst offender for runtime space overhead[1], and it's CLOS implementation is heavily biased towards the "space" side of the time/space tradeoff, and a brief look at the implementation of this shows a lot of CLOS usage. I would expect that delivering with a different implementation would show a significant reduction in size.

Barring that, most GUI executables are fairly insensitive to startup time, so SBCL core compression would the lisp image down by a factor of 4:1.

Lastly, you can always just not worry about it:

    du -s /Applications/*.app | sh ~/avg.sh
    Total: 28529040; Count: 126; Mean: 226420; Median: 56752; Min: 8; Max: 6132408

1: Note that SBCL generates the best code of any Free lisp implementation, and makes it the easiest to tune your code for better performance. As disk space is cheap, it's what I use for most of my applications.

Hey, eudox! We wanted to ask you, but we did not see you on the Reddit thread. Someone asked:

https://www.reddit.com/r/Common_Lisp/comments/3d3oqh/ceramic...

The gist is: for the Javascript parts on your site, any plans to integrate Parenscript for the full Lisp experience?

Thanks for your work. I saw again it was posted before today on /r/lisp and /r/programming, but I missed it.

Thanks!

The only JavaScript is in the Electron process, and it's fixed, ie you don't have to touch it. You interact with it through CLOS methods on window objects.

Other than that any JavaScript is optional, you write it yourself (using whatever source language, e.g. ParenScript) and ship it with your app as a resource.

Reply on news.ycombinator.com