Clément Pit-Claudel <
address@hidden> schrieb am Sa., 8. Apr. 2017 um 17:15 Uhr:
On 2017-04-08 11:03, Philipp Stephani wrote:
> Clément Pit-Claudel <address@hidden schrieb:
>> … essentially everything in packages that were previously
>> preloaded needs to be autoloaded now, since many packages don't
>> (require) the preloaded features that they use.
> Doesn't that effectively just move most of the code to loaddefs.el,
> from which it again has to be either preloaded or byte-compiled into
> the "big .elc file"? Does this really bring measurable benefits
> nowadays?
(Sorry if I'm misunderstanding you)
I think the idea is that you can defer loading the implementation of a significant fraction of currently-preloaded functions, because many of these are currently unused.
So the intended saving is that currently-preloaded but uncommonly-used functions would not be dumped to the big-elc (their signatures, in the form an autoload, would be). Packages that use them without (require)-ing the corresponding feature first would still work, but startup would be faster.
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.
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, ...).