Re: Finalizing 'inhibit-automatic-native-compilation'

[Eli Zaretskii]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Sat, 4 Feb 2023 17:05:19 -0500
> Cc: rms@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> On Sat, Feb 4, 2023 at 3:08 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > Something in emacs is putting advice on call-interactively.  When I
> > > extended the baseline dump to include essentially all libraries
> > > included with emacs with native-compilation, it caused an infinite
> > > (asynchronous) regress while compiling the trampoline for
> > > call-interactively.  I wasn't aware of this until /tmp filled up.
> >
> > Is this with Emacs 28 or Emacs 29?
> 
> This was with 28.1 modified to support dumping with many pre-loaded
> native-compiled files.

I asked because Emacs 29 adds some changes specifically intended to
solve the problem of infinite recursion in trampoline compilation.

> As far as I know, emacs still doesn't support dumping arbitrary
> native-compiled libraries at compile-time.

What problems do you see if you try?  AFAIR, if you tweak
native-comp-eln-load-path so that the *.eln files you want to dump are
directed to the ../native-lisp directory relative to where the Emacs
binary lives, then dump Emacs, loading such a dumped Emacs should
work.

Andrea, am I missing something?

> Which is too bad, because the dumped version is a LOT faster to
> startup.

Are you sure? is this with native-compilation or without it?

> As per the other recent thread (3x increase in startup time),
> loading eln files seems to be considerably slower than loading elc
> files at startup, but in dumped images the difference is probably
> the other way around.

I don't see why it would be faster when loading a dumped Emacs: the
pdumper file records only the names of the *.eln files, not their
contents, so Emacs still has to load all of the *.eln files recorded
in the pdumper file, and that takes time and doesn't change much when
the names are recorded in emacs.pdmp.

> I've
> since approximated that dump with a byte-compiled version and the user
> function dump-emacs-portable, but then I have to install before-init
> hooks to systematically replace occurences of the user name and home
> directory in variables and customizations to make the dump usable.
> It's a kludge no distro would want to use.  Even then there are a
> handful of libraries that have to be kept out of the dump (using bogus
> "(provide <x>)" expressions) and then explicitly loaded in an
> after-init hook after removing the bogus features. And they aren't
> consistent with the ones that were problems for native-compiled
> dumping.  But my point is, loading that byte-compiled dump takes
> somewhat longer than loading the native-compiled dump that had twice
> as many pre-loaded libraries.

If you want to dump more libraries than Emacs does by default, why not
modify loadup.el to load those libraries at build time?  Then they
will be dumped together with all the rest, and the loading won't need
any changes on your side.

> Emacs needs a lot more work to really support compile-time dumping of
> a larger set of libraries.  There are too many instances of code
> evaluated at load time that should be evaluated in a before-init or
> after-init hook, that depend on variables set in C code after the dump
> file is loaded.  Or run-time services like dbus.  To really support
> site-specific dumping, a robust analysis identifying that code and
> transforming it appropriately would have to be performed either prior
> to or as part of dump-mode.  It's non-trivial.  The changes to the C
> code to deal with additional objects like text properties while
> purifying are (or were) trivial by comparison.

I guess this is true, at least to some degree.  Patches to this
effect are welcome.