[armedbear-devel] Optimizing loading times: different strategy for externalizing

Erik Huelsmann ehuels at gmail.com
Tue May 18 12:17:55 UTC 2010

The other day, there was some discussion regarding object-equality
from loaded fasls. I'm going to leave that discussion out of the mail
below: the mail below is about efficiency of what we do today.

As described by Alessio, it looks like our loading process profiles
are dominated by reader functions. So, I've taken a look at what it
actually is that we serialize. I found that many things we serialize
today - which need to be restored by the reader - can be serialized
without requiring the reader to restore it: lists of symbols and

That's where I decided to take a look at today's serialization
mechanism. Roughly speaking, those are the functions in
compiler-pass2.lisp with a function name starting with DECLARE-*; the
namespace seems to contain functions for externalizing objects as well
as for caching constant values.

On trunk, I'm working to:
 * separate the caching from the externalizing name-spaces
 * separate serialization and restoring functionalities in different functions
   (they were conflated in a single function for each type of object)
 * define serialization functions which allow recursive calling patterns for
   nested serialization of objects (to be restored without requiring the reader)

For each of these bullets, I'm making good progress; the second bullet
is done, although not all serialization functions have been moved over
to that namespace and approach yet. The last bullet is nearly done.

When each of the above is done, we will have all the building blocks
required for quick elimination of the reader in a number of obvious
cases - such as function argument lists.

Hope you find this update useful.



More information about the armedbear-devel mailing list