[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
optimization versus constructors
- To: Common-Lisp-Object-System@Sail.Stanford.edu
- Subject: optimization versus constructors
- From: Gregor.pa@Xerox.COM
- Date: 15 May 87 11:07 PDT
Danny and I have been thinking about initialization and are picking away
at parts of the problem we don't understand. Specifically, I was trying
to remember what the :constructor option was really for. I remembered
that:
- it isn't really just an abbreviation for a defun and a call to
make-instance since it can set slots which are not settable by initargs.
- even if it was just an abbreviation for a defun with a call to
make-instance, the constructors generated by the :constructor option
would be much faster than the ones defined by calling make-instance by
hand.
This message addresses the second of these 2 points. Specifically, I
will show a simple (even trivial) technique which reduces optimizing
calls to make-instance to exactly the same problem as optimizing
constructors produced by :constructor option. This is important because
it means that we can think about constructors only in terms of their
behavior, they are not needed for performance anymore.
The basic idea is that a call to make-instance with a constant first
argument and constant key (even numbered) args can be treated as a
dynamic definition of an :constructor with some gensymed name.
So that in the form
(progn .. (make-instance 'boat :speed 10) ..)
the call to make-instance can be converted to something like:
(progn .. (#:G001 10) ..)
and the class gets updated as if it had had a :constructor option
(:constructor #:g001 (speed)).
This shows that whatever optimization can be gotten from the
:constructor option can also be gotten from calls to make-instance (at
least the calls to make-instance for which you could have used a
constructor).