[kunabi]

I've been working on a CL project for a couple of years. Was my first big stab at using CL for something other than a toy. Sbcl is a nice choice, but far from the only option. It has many tradeoffs. CL is not without its frustrations. Documentation that has not aged well. A community that can be less than welcoming. (in contrast to say the Racket community) Inconsistencies, e.g. first, nth, elt, getf, aref... However portability appears to be a strong point vs on the scheme scene. Single binary compilation on SBCL/LW/ACL/CCL are great. Found GC to sbcl to be lacking on large garbage rates. Tended to promote garbage to a tenure that prevented it from being removed. It would max out 32GB of memory, even with explicit gc's enabled between files. Where as the other implementations would stay below 4GB.

So ymmv.

Performance benchmarks using cl-bench really highlighted some strong points http://zeniv.linux.org.uk/~ober/clb AWS Cloudtrail parser. https://github.com/kunabi/kunabi

[azrazalea]

This talks about GC settings that worked for them in SBCL for production, not sure if you already tried the same kind of stuff but may be an interesting read http://tech.grammarly.com/blog/posts/Running-Lisp-in-Product....

If you can make an easy to run example of the garbage collector not working correctly, the folks in #sbcl on freenode are very responsive and have commit access to fix it.

[kunabi]

Good to hear someone had good interactions in #sbcl Still have a bitter taste from attempting to report the issue there.

[azrazalea]

Yeah, i've had good and bad interactions.

They seem to be cranky due to getting a lot of idiots (including sometimes me) coming in thinking something is sbcl when it was actually the programmer's fault.

Generally if I think something is sbcl now I put together example code that clearly shows the issue and that seems to work well.