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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philippe Vaucher <philippe.vaucher <at> gmail.com>
Cc: p.stephani2 <at> gmail.com, eggert <at> cs.ucla.edu, 23529 <at> debbugs.gnu.org
Subject: Re: bug#23529: Request for fixing randomize_va_space build issues
Date: Sat, 10 Sep 2016 09:13:18 +0300

> From: Philippe Vaucher <philippe.vaucher <at> gmail.com>
> Date: Fri, 9 Sep 2016 22:00:43 +0200
> Cc: Philipp Stephani <p.stephani2 <at> gmail.com>, 23529 <at> debbugs.gnu.org, 
> 	Eli Zaretskii <eliz <at> gnu.org>
> 
> >> A typical non-trivial Emacs session takes several seconds, sometimes
> >> 25 or more, to start
> >
> > ?! That may be typical for *you*. It is not typical for me. On the six-year-old desktop at work that I'm using to
> type this message (hard disks, no flash) in normal mode, Emacs by default takes 1.2 seconds to start up.
> Even 1.2 seconds is too long, as I start up Emacs a lot.
> 
> I second that, most people load emacs in less than 7 seconds, and below 2 when they use use-package or
> equivalent. That is for emacs with 50+ packages.

Didn't I say "several seconds"?  Where's the contradiction?

Several seconds is a lot of time for modern CPUs, address fixup is a
rather cheap operation.  That's what the dynamic linker does every
time you load a shared library -- did you ever find that loading
annoyingly long?

> I agree with the spirit: we should try to simplify & modernify emacs. Adding something very custom sounds
> like another maintenance hell.

Excuse me, but how is relying on compilers and linkers more "modern"?

"Maintenance hell"?  Did you see how many changes in Emacs are done to
adapt Emacs to some particular compiler on some particular system?  I
suggest you take a look at "git log" (search for "Port "), keeping up
with that is no less "maintenance hell" than maintaining our own code.

Previous Next

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