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.