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 lists.
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.
Bye,
Erik.