[Ecls-list] Improving CLOS?

[Juan Jose Garcia-Ripoll]

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

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100319/5ba69add/attachment.html>