Re: Regression in dump-emacs-portable

[Lynn Winebarger]

On Thu, Feb 23, 2023 at 10:08 AM Gregory Heytings <gregory@heytings.org> wrote:
> > I mentioned redumping a maximal set of core emacs libraries under 28.2
> > in a recent thread.
> >
>
> Just out of curiosity: what is the purpose of doing that?  You already
> mentioned several times that you are trying to create a "fully-loaded"
> Emacs, with as many packages as possible in the dump file (IIUC), but
> without explaining why (IIRC).

I've been an emacs user for a pretty long time though with frequency
depending on how much coding I happen to be doing in my leisure time.
In my day job, I've been using other editors/IDEs.  So while I enjoy
pretending I am a grad student at MIT's AI labs on Symbolics LISP
machines circa the mid-late 1980s, I am curious about the extent to
which Emacs has the features of these other editors,  In terms of
technical design, VSCode is probably the closest, in terms of much of
the interface being implemented in a dynamic language accessible to
the user at run-time.  V8 even provides a form of dumping, although I
don't know that VSCode supports it for end-users.  So, while I can
appreciate the desire for a parsimonious build that can be run with
limited resources, the competitor products regularly use 100-200MBs in
a process and I see no reason to avoid processes using similar amounts
of resources.
I've also historically used the default settings of Emacs for the most
part.  But if I want to see how optional features provided by packages
actually work, I want to be able to turn them on and off in an
options-type menu the way I would in these other editors.  Some
libraries/packages provide customizations via autoload, but to really
be sure you see all the knobs (and get some notion of what the
functionality might be), the packages have to be loaded.  Loading a
bunch of libraries/packages (particularly packages) at startup can be
slow.  If you load 1000 packages plus emacs, that can easily take 2+
minutes to load.  At 2000-2500 packages, 5 minutes is a fair
expectation.  When I was doing this with native-compiled modules, it
was paradoxically even slower.  Dump files, whether build-time dumps
or redumps, are just much much faster to load.  Plus, it's the closest
thing emacs's garbage collector has to a compacting generational
collection.  Loading libraries creates plenty of garbage but also the
longest-living objects in the system, so it makes the GC more
efficient to ensure those objects are compacted.
Ultimately, I think it would be fun to write support for a modular
dump file format for more efficient library loading.  But first, it
makes sense to understand the functionality already available and
measure its performance for benchmarking purposes.  And encourage
others to make use of those facilities, so they do not wither on the
vine.

Lynn