Beyond correctness and conformance: applicability and performance

Last time was about how the team is working to advance ABCL's correctness and conformance; these two are mostly measured by the ANSI tests. Next to those characteristics, we also introduced a measure called 'applicability'. It's a qualitative measure which we say increases when (more) existing Lisp code is made to (or is proven to) work with ABCL.

So far, we've been using the following software to test (and improve) the applicability of ABCL:

• Maxima
• AP5
• cl-bench
• SLIME/swank

Next to the above we know a number of people are using ABCL to write their own applications. See the testimonials page. If you have software to complete the list of known-working software, please contact our developers list. If you have software which is almost working, please help us improve our applicability by at least reporting; patches to resolve the situation are even more appreciated.

Another aspect of our user experience is performance. Being an implementation on the JVM, of course we're restricted in many ways on which code we can generate and how we store our data. As a result we'll be in a disadvantageous position to start with.

That doesn't mean there's no room for improvement in ABCL at the moment. The development team has gradually moved into the area of profiling and improving the implementation over the last 2 or 3 months. As it turns out, there's still a lot which could be improved, with the following examples:

• Support for unboxed single-floats and double-floats in the compiler
• Careful creation of new objects - focussing on re-use - in the support library
• Prevent unnecessary re-opening of system files (fasls and others)
• Prevent unnecessary loading of compiled files (which clear out the HotSpot caches)
  

As you can see, more parts and more aspects of the system are receiving our attention.