Re: When should ralloc.c be used? (WAS: bug#24358)

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, npostavs@users.sourceforge.net, emacs-devel@gnu.org
> Date: Thu, 27 Oct 2016 16:39:59 -0400
> 
>   > Eli has mentioned a simpler approach, where we build an .elc file when 
>   > saving Emacs state and load the .elc file during normal startup. The 
>   > main worry about this approach is performance.
> 
> There is no reason why we have to choose between C code and Lisp code.
> It's worth developing a special-purpose format for this, if that would
> be considerably faster.

The Lisp approach has a huge advantage: it is much simpler, so
everyone here will understand it, and it is much easier to maintain
and develop.

So if the performance hit is bearable (meaning will be accepted by the
crowd), it should IMO be preferred for reasons of project management
and its future, even though faster methods exist.  IOW, the goal of
bringing the unexec out of the shadows of system-level black magic it
is now should stomp the "faster is always better" principle, if we
care about the future of Emacs in the face of the fact that fewer and
fewer people know, or even want to know, about segments and offsets in
a binary executable file.

And speaking about performance: I suggest people who worry about that
start by comparing startup times of past versions of Emacs.  Using
this simple benchmark proposed by Andreas:

  time emacs -batch --eval t

I see that we've been consistently adding 10% of startup time with
each major release, beginning with Emacs 23, so 25.1 starts about 25%
slower than 22.3.  If that didn't cause an outcry, then perhaps our
concern for this order of magnitude of differences in startup time are
a tad exaggerated?