On Fri, Mar 19, 2010 at 10:03 AM, Andy Hefner <ahefner@...> 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)