bug#23529: Request for fixing randomize_va_space build issues

[Eli Zaretskii]

> Cc: p.stephani2@gmail.com, 23529@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 13 Sep 2016 08:51:47 -0700
> 
> Eli Zaretskii wrote:
> > the idea is to dump the dumping (pun intended), and instead
> > load the preloaded packages upon each session start.
> 
> This approach could well work. It addresses the portability concerns with 
> malloc, as it means we can just use the system malloc. If it has acceptable 
> performance and its bugs can be fixed, it would be a good way to go.

That's the goal, yes.

> My main worry is performance. On the desktop that I'm typing this message on, 
> emacs -Q takes about 40 ms to start up in batch mode, about 90 ms in a 
> terminal, 
> and about 300 ms on a graphical display. These are the sorts of times that 
> I'd 
> like to see with the proposed approach too. (This desktop is using a 
> 4-year-old 
> Xeon E3-1225 V2 CPU, and Emacs is stored on flash and typically cached in 
> RAM.)

I don't see why we couldn't keep these times, or come close, if your
disk is flash memory.  I got 0.2 sec with a real disk, in a 32-bit
build with wide ints, and that was without any serious attempt to find
the hot spots and optimize them.

> By "dump the dumping" I assume you mean withdraw the traditional dump-emacs 
> function.

Yes.  Instead, there should be mostly Lisp code to produce a single
.elc file for all the preloaded stuff, and calculate values of some
variables that can only be recorded at build time (like
source-directory, for example).