Re: Skipping unexec via a big .elc file

[Ken Raeburn]

On Dec 19, 2016, at 10:09, Phillip Lord <address@hidden> wrote:

> I looked at this a little and in fact the boot code that I have written
> does tell you exactly which autoloads you need to get temacs to work --
> it's not very many, I think that there are only 10 or so (bytecomp.el
> for instance).

This sounds like it could be the biggest help for startup time at this point.  
Are you going to look further into making a lightweight loadup file?

Looking at ldefs-boot.el and loaddefs.el, and contemplating the parsing of 
them, I wonder: If we go the big-elc route, can we defer loading the doc 
strings until they’re actually needed?  Perhaps using the “(#$ . nnnn)” syntax 
used in .elc files, or somehow pointing at the real .el or .elc files defining 
the functions?  Maybe just omit the function doc strings, if the help code does 
something reasonable in that case?

I’ve still been poking at the reader code, but for small-ish changes I think 
I’m hitting a point of diminishing returns.  My current test case run time is 
about 0.15-0.16s, though the run times are short enough that minor system 
activity at the same time can affect the results.  I’ve got one more experiment 
in the works that cuts almost 20% of the size of dumped.elc, and cuts the test 
run time to about 0.14s.  (Sharing interned symbols in the printer, so 
“setplist … setplist …” becomes “#4=setplist … #4# …”, drastically cutting into 
the 90% of oblookup calls that are done for symbols already in the obarray, and 
the related string manipulations, as well as the legibility of the generated 
file.)  After that, I think the next step is further specialization of 
read1/readchar/read_escape/readbyte for the get-file-char case, and maybe more 
tweaks to try to optimize for mostly-ASCII input.  But those result in more 
code duplication and additional maintenance work, for probably small benefit, 
so they’re not looking all that appealing.

So, at this point, I’m inclined to finish my current experiment with the 
printer, and maybe set aside work on the big-elc performance for a bit, maybe 
look into threading bugs or the state of the CANNOT_DUMP code.

Ken