Re: Skipping unexec via a big .elc file

[Ken Raeburn <raeburn@raeburn.org>]

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