Re: Skipping unexec via a big .elc file

[Ken Raeburn]

On Oct 24, 2016, at 09:13, Stefan Monnier <address@hidden> wrote:

>> Did you check whether actually byte compiling the written file made
>> a difference?
> 
> dumped.elc has no code to compile.

It has a lot of fset and setplist calls which can be compiled, especially if 
you reorder things such that they’re not mixed up with the defvar calls that 
don’t compile.  The generated .elc output is about 25% larger.  I don’t expect 
the C parts of fset and setplist to be affected at all, of course; the parsing 
and interpretation of the Lisp may be another matter.  Unfortunately, 
byte-compile-file doesn’t preserve the sharing of objects (“#42#”) present in 
the input file, so the output isn’t semantically the same.

I did some profiling.  Without byte compiling, it appears that around half of 
the CPU time used loading the file in my test is spent in 
Frassq(…,read_objects), called from substitute_object_recurse.  For processing 
a file with this much sharing of objects, an assoc list with O(n) access time 
may not be the best choice.  Whatever we replace it with, it appears we need to 
be able to look up cons cells in a collection by either element.

The next top users of CPU time (_IO_getc, oblookup) are less significant, 
though there are some easy minor gains to be made there.

With a hacked-up 31-slot hash table replacing read_objects, the getc_unlocked 
changes, and setting OBARRAY_SIZE to 8191, I got the load time for the file in 
batch mode on my test system from just under a half second to about a quarter 
second.  Nearly half the remaining CPU time is split between readchar, read1, 
readbyte_from_file, and Fassq.

Ken