On Fri, Mar 19, 2010 at 10:03 AM, Andy Hefner <ahefner@gmail.com> wrote:
IMO, ECL's non-CLOS performance is sufficiently lackluster that
special effort spent optimizing CLOS would be misdirected.

Not really. Things can be worked out in parallel, as they are _totally_ unrelated. CLOS performance is different from compiler optimizations, declarations, core library performance, etc.

I am just dropping ideas for people to catch them up, specially those that are easy to implement. If what you mean is that _I_ should focus on other stuff, then maybe you are right, and in the case of a single developer the focus should be different.

How can CLOS be sped up:

- Right now there are two branches for function calls: dispatch on object type and then dispatch on whether it is ECL's generic or not. Flatten this, maybe including other C types (t_instance -> t_instance, t_simple_funcallable, t_generic_funcallable, ...)

- Instead of having ONE dispatch function, implement several smaller ones that can be used when we do not have a complicated generic function: no EQL specialization, no AFTER, etc.

- Revise calling conventions for methods and how their lambda functions should look like.

- Revise optimizations for slot access. We had to remove ALL optimizations because of the MOP. Look for ways to restore this back.

Where would this have a greater impact:

- Libraries that make intensive use of CLOS. Some people enjoy using CLOS for programming, and many libraries out there use it more often than they should -- cl-unicode, for instance.

- I/O by means of FORMAT, Gray streams, PPRINT, all these routines depend exclusively on CLOS for performing input and output.


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)