Re: Skipping unexec via a big .elc file

[Ken Raeburn]

One area I’m contemplating now is whether we can trim the size of dumped.elc.

Question: How useable does Emacs need to be if the Lisp code is improperly 
installed (or not installed) and can’t be loaded?

With the big-elc approach as currently implemented, assuming we store 
dumped.elc in the install tree along with the other Lisp code, it basically 
can’t start without that Lisp library.

If that’s okay, then the next question is: How much do we *need* to load before 
processing user input?

My impression has been that the current loadup.el contents cover not just the 
bare minimum that Emacs absolutely needs to have to function, but also the 
popular things we want to have readily available without having to wait for a 
Lisp package to load (like buff-menu), especially if it’s in response to a 
simple keypress or mouse click.  (The X support code is loaded in an X build, 
even if no X display is present at startup; I think parts of it fall into both 
categories.)  And adding stuff is fairly cheap; loadup and unexec can take as 
long as they want, only the speed of relaunching the resulting executable 
affects the user.

With the big-elc approach, the tradeoffs change.  Reading a bunch of function 
definitions from dumped.elc is only a tiny bit faster than reading the same 
definitions from the original .elc files, because we don’t have to open more 
files.  (At least, the cost is trivial if the files are in cache.  It’ll be OS- 
and system-dependent.)  Only the time for precomputation that gets done as the 
file is loaded is saved, and exchanged for the time needed to parse the saved 
result.

If we can trim some stuff from loadup.el, and resort to autoloading that stuff 
later, that may save us some startup time.  (Some text mode commands?  Or 
buff-menu?)

If we really want some of the other stuff to be able to run immediately when 
the user hits a key, maybe there’s some way to compromise between that and 
faster startup.  A strawman proposal: load the “must-haves” via dumped.elc; 
load the user’s init file, read files and execute eval commands as indicated by 
the command line options; check for user input; if there’s no user input (e.g., 
use an idle timer set for 3s), start going through a list of “nice-to-haves” 
and loading them, continuing until user input is available.  If the user starts 
typing or otherwise invoking some of those nice-to-have commands right away, 
they’ll have to wait while autoloading happens, but if we get a couple idle 
seconds, we may still pull the commands in before the user needs them.

Of course, if the user types something while we’re loading a file, that file 
will have to finish loading before we can respond; it’s sort of a guessing game 
as to how much idle time suggests that the user is doing something else and 
probably won’t type anything in the next second or two.  Perhaps we can divide 
the task further to keep any individual delay shorter: read a .elc file into a 
buffer, check for input, parse into S-expressions, check for input, eval the 
S-expressions…

Ken