Re: Skipping unexec via a big .elc file

[Eli Zaretskii]

> From: Philipp Stephani <address@hidden>
> Date: Sat, 08 Apr 2017 15:53:49 +0000
> 
> The question is whether there is actually a significant speed-up.
> Autoloading is traditionally used for a small number of interactive commands 
> that cause large optional libraries
> to be loaded. In such cases I could imagine that the performance gain is 
> still significant. However, you now
> suggest that preloaded libraries get turned into autoloads. The structure of 
> those libraries is typically quite
> different: the consist to a large extent of individual helper functions that 
> are independent of each other. My
> guess is that this could make overall performance worse: it will cause 
> loaddefs.el to contain all the signatures
> and docstrings of these helper functions, and loaddefs.el is itself not 
> byte-compiled. Therefore, you now need
> to load the definitions effectively twice: once in loaddefs.el, once the 
> functions are actually used. Therefore
> such a change shouldn't be made without measuring its impact.

This issue will not be resolved by guessing, but by measurements.  So
if you are interested and can produce a dumped.elc that only loads
what's necessary in -batch session, and that dumped.elc does or
doesn't load significantly faster than the full one, we will know who
is right here.

Thanks.

> I'd actually prefer going into the other direction: preload much more than 
> now, and remove lots of stuff from
> autoloads. This will probably need a different strategy for preloading 
> (Daniel's approach, or Rmacs, or an Elisp
> LLVM compiler, ...).

Given that load time is an issue, loading more stuff than strictly
necessary seems to make very little sense to me.