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

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Stallman <rms@gnu.org>
> CC: eggert@cs.ucla.edu, npostavs@users.sourceforge.net,
> 	emacs-devel@gnu.org
> Date: Fri, 28 Oct 2016 15:12:27 -0400
> 
>   > 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.
> 
> The special format I propose is simple enough.

For you and me (and a few others), maybe.  For most of the current
Emacs contributors it's nowhere near "simple enough", because it
requires one to be familiar with intimate details of Emacs object
design and implementation.

IOW, for the purposes of this discussion, I consider anything that is
not mostly Lisp "not simple".

>   > 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,
> 
> Slowness here affects every user and is quite noticeable.
> Don't we already know that Lisp is too slow for this?

No, we don't know that, because we never tried to implement any method
of reading compiled Lisp that is optimized for speed and targets a
bare Emacs.

E.g., it turned out that most of the time it takes 'loadup' to do its
job is due to the linear search of pure strings in
find_string_data_in_pure, called by make_pure_string.  If we call
'loadup' upon every startup, the need for pure storage goes away, and
the 'loadup' time can be sped up tenfold.  And that is even before
making all of the preloaded files a single file, which speeds up
things at least twofold more, according to my measurements.

So here you have a 20-fold speedup just by two very simple measures.

>   > 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.
> 
> That is an argument for replacing unexec with something that saves the
> data to reloed, but it is not an argument for using Lisp as the format.

It is an argument for both, because I don't think we can count on too
many people here being able to tinker with Lisp object internals in
the future.  The less such features we have that will need
maintenance, the better for Emacs viability in the long run.

>   >   time emacs -batch --eval t
> 
> I just tried it with my current build (from June).  It took .26 seconds,
> which is fast enough.
> 
> If replacing unexec with loading Lisp takes .05 seconds more, I won't
> complain.  But I think it will take several seconds, if not minutes.

How much does it take on your system to do this:

  time src/temacs -batch -l loadup

And if you modify Emacs with the patch posted here:

  http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01049.html

how long does it take temacs to loadup then?