GNU bug report logs - #23529
Request for fixing randomize_va_space build issues

Previous Next

Full log

Message #203 received at 23529 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: philippe.vaucher <at> gmail.com, p.stephani2 <at> gmail.com, 23529 <at> debbugs.gnu.org
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
Date: Tue, 13 Sep 2016 22:24:42 +0300

> Cc: p.stephani2 <at> gmail.com, 23529 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> 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).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.